¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Testdrivendevelopment
  2. Topics

How do I unit test a Dispose method ?

[email protected]
 

Whoops just saw yesterday's message came in all garbled..

here it is again properly formatted..


==========================


Hi again Gishu and all,?


Seems like this thread has grown since I last looked :)


What I used to do in this case is inject the disposable object as a collaborator (interface representing its role) into the class that uses it,?


so the class that uses it doesn't need to know about if it is or isn't disposable.


E.g:?


class connection?

{

?ISecurePassword pswd?

}


interface ISecurePassword?

{?

?Void doSomethingThatSecurePasswordsDo();?

}


class DispisableSecurePassword : ISecurePassword, IDisposable

{

? ...?

}


Application:

void Main(){

? using (DisposableSecurePassword pswd = new DisposableSecurePassword())

? {

? ? Connection conn = new connection(pswd):

? ? conn.DoSomethingThatNeedsToBeDone();

? }

}


Makes any sense??


Written hastily from iPhone waiting for a buss


Avi
[email protected]
 

Hi again Gishu and all, Seems like this thread has grown since I last looked :) What I used to do in this case is inject the disposable object as a collaborator (interface representing its role) into the class that uses it, so the class that uses it doesn't need to know about if it is or isn't disposable. E.g: Class connection { ISecurePassword pswd } Interface ISecurePassword { Void doSomethingThatSecurePasswordsDo(); } Class dispisableSecurePassword : ISecurePassword, IDisposable{ ... } Application: Using (disposableSecurePassword pswd = new disposableSecurePassword()){ Connection conn = new connection(pswd): ... } Makes any sense? Written hastily from iPhone waiting for a buss Avi
 

Nope. I did test-drive this design.
The connection instance represents an open connection to a hardware device. All conn parameters appear as constructor parameters of this type - one of which is a SecureString password.
Connection(conn params)

The type creates a copy of the same in the ctor and holds on to it for subsequent API calls to the device

Finally it has a Disconnect method that closes the connection.

My problem is detecting whether disconnect disposed of the 'disposable' member fields.
Subclassing and overriding Dispose is an option
override void Dispose()
{
?? base.Dispose();
?? // check if this.Password has been disposed
}

However there isn't any clean way to know this - unless IDisposable interface had a bool IsDisposed property.
A crude way would be to invoke another member and expect an ObjectDisposedException (if the type has been well written)
[email protected]
 

Hi Gishu


Sorry if my reply is out of context - I've been having trouble finding all the replies in the new (?) Yahoo group UI....


In general - the idea is the tests drive your design.

Here it sounds like you have a predefined design (a Connection wrapping your disposable SecireString member) and now you want to test iot (after the code is written).

Did I understand that correctly?


Either way - TDDing this would probably produce a whole different design, depending on your requirements... I'd love to give it a go - could you give some more context? as to how you ended up with this design and what the requirements are?


Best,

Avi
 

The question is a bit .Net specific.
Assuming the simple case, where I have a type which wraps a internal IDisposable member.

class Connection
{
?? private SecureString password;
}

SecureString is Disposable. That mandates that Connection should have a Dispose method, which should dispose its members.

Options:
* To know whether the internal member has been disposed, I'd have to expose it (so that the unit test can see it). Doesn't feel right to me.
* The other hack would be to promote it from private to internal + use the InternalVisibleTo path to access it.

Does anyone have something better ?

Gishu

1 - 5 of 5