How can I write a unit test for a method that has a using statement?
For example let assume that I have a method Foo
.
public bool Foo()
{
using (IMyDisposableClass client = new MyDisposableClass())
{
return client.SomeOtherMethod();
}
}
How can I test something like the code above?
Sometimes I choose not to use using
statement and Dispose()
an object manually. I hope that someone will show me a trick I can use.
Your question doesn't make sense. If you are doing TDD, then the method that you posted is already fully tested, otherwise it couldn't even exist in the first place. So, your question doesn't make sense.
If, on the other hand, the method that you posted does already exist, but isn't fully tested, then you aren't doing TDD anyway, and your question about TDD doesn't make sense, either.
In TDD, it is simply impossible for untested code to exist. Period.
If you construct the
IMyDisposableClass
using a factory (injected into the parent class) rather than using the new keyword, you can mock theIMyDisposable
and do a verify on the dispose method call.Wrapper methods like that aren't unit-testable, because you can't specify the relevant preconditions or post-conditions.
To make the method testable, you'll have to pass an
IMyDisposableClass
instance into the method or into the class hostingFoo
(and make the host class itself implementIDisposable
), so you can use a test double instead of the real thing to verify any interactions with it.Your question doesn't make sense. If you are using TDD, then you should already have a test for what you have written. Requirements, then tests, then design, then development. Either your code passes your tests, or it doesn't.
Now, if your question is how to unit test the above piece of code, then that's another question completely, and I think the other posters have answered it up there.
Sometimes I think there are more buzzwords than developers :)
If you already have your code and are asking how to test it, then you're not writing your tests first...so aren't really doing TDD.
However, what you have here is a dependency. So the TDD approach would be to use Dependency Injection. This can be made easier using an IoC container like Unity.
When doing TDD "properly", your thought processes should run as follows in this sort of scenario:
Foo
IMyDisposableClass
IMyDisposableClass
into the class in whichFoo
is declared via its constructorThen you would write one (or more) tests that fail, and only then would you be at the point where you were writing the
Foo
function body, and determine whether you needed to use ausing
block.In reality you might well know that yes, you will use a
using
block. But part of the point of TDD is that you don't need to worry about that until you've proven (via tests) that you do need to use an object that requires this.Once you've determined that you need to use a
using
block you would then want to write a test that fails - for example using something like Rhino Mocks to set an expectation thatDispose
will get called on a mock object that implementsIMyDisposableClass
.For example (using Rhino Mocks to mock
IMyDisposableClass
).Class in which your Foo function exists, with
IMyDisposableClass
injected as a dependency:And the interface
IMyDisposableClass
If you are testing Foo, then you should be looking at the output of Foo, not worrying about the disposal of the class it is using internally.
If you want to test
MyDisposableClass
' dispose method to see if it is working, that should be a separate unit test built againstMyDisposableClass
.You don't need to unit test the
using { }
block, since that is part of the language. You either trust that it's working, or don't use C#. :) I don't see the need to write a unit test to verify thatDispose()
is being called.