Take the 2-minute tour ×

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.

share|improve this question
What is TDD? The only expansion I know of is Test-Driven Development. –  Michael Myers Dec 23 '09 at 16:09
It is Test Driven Development. –  Vadim Dec 23 '09 at 16:10
So your question is "How can I test-driven development something like the code above?" –  Michael Myers Dec 23 '09 at 16:11
Test-driven develop. Cut some slack with the conjugation :) –  mgroves Dec 23 '09 at 16:25
Well, I was also trying to point out that you can't "test-driven develop" code that already exists. But that's been mentioned in several answers now. –  Michael Myers Dec 23 '09 at 16:33

7 Answers 7

up vote 13 down vote accepted

If you construct the IMyDisposableClass using a factory (injected into the parent class) rather than using the new keyword, you can mock the IMyDisposable and do a verify on the dispose method call.

share|improve this answer
Alternately, you can use a virtual factory method, and test a specialization of that object that returns an appropriate mockable instance. When looking at code, remember that the new operator is a static dependency - there are other good reasons to avoid its use in non-factory objects, too. –  kyoryu Dec 24 '09 at 3:22

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:

  • I need to do a Foo
  • For this I will rely on an external dependency that will implement an interface (new or pre-existing) of IMyDisposableClass
  • Therefore I will inject an IMyDisposableClass into the class in which Foo is declared via its constructor

Then 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 a using 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 that Dispose will get called on a mock object that implements IMyDisposableClass.

For example (using Rhino Mocks to mock IMyDisposableClass).

public class When_calling_Foo
    public void Should_call_Dispose()
        IMyDisposableClass disposable = MockRepository

        Stuff stuff = new Stuff(disposable);


        disposable.AssertWasCalled(x => x.Dispose());

Class in which your Foo function exists, with IMyDisposableClass injected as a dependency:

public class Stuff
    private readonly IMyDisposableClass _client;

    public Stuff(IMyDisposableClass client)
        _client = client;

    public bool Foo()
        using (_client)
            return _client.SomeOtherMethod();

And the interface IMyDisposableClass

public interface IMyDisposableClass : IDisposable
    bool SomeOtherMethod();
share|improve this answer
I'm sorry Richard but your answer is not very helpful. I've written a lot of DI code and used many different Inversion of Control containers including Unity. I'm working on legacy code that has only integration tests. I like mcintyre321 answer where he suggests to use a factory. It's very helpful I can implement it. If you read my question completely you would read "Sometimes I choose not to use using statement and Dispose an object manually." –  Vadim Dec 23 '09 at 16:41
I have modified the question to make it clearer that this is testing existing code, not TDD. –  Jay Bazuzi Dec 23 '09 at 17:15
TBH it's pretty much the same answer I gave, except I'd have the constructor of Stuff like Stuff(Func<IMyDisposableClass> myDisposableFactory) –  mcintyre321 Dec 23 '09 at 17:27
@Richard, I only inject a factory Func (or a real Factory interface) as opposed to the dependency if the class has to manage the whole lifecycle of the dependency (e.g. create it and destroy it) or create multiple instances. See 'auto-generated-factories' in AutoFac 2 for a nice way for this to work (code.google.com/p/autofac/wiki/NewInV2) –  mcintyre321 Dec 24 '09 at 10:08
What happens when someone calls Foo() twice for the same instance of Stuff? –  Seph Sep 3 '13 at 11:29

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 :)

share|improve this answer
Amen. It's incredible to watch people consistently struggle with the wrong tool (regex, LINQ) or the wrong approach (DDD) because it's "hot" and they just want to be "cool." Plus one. –  jason Dec 23 '09 at 17:30

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 hosting Foo (and make the host class itself implement IDisposable), so you can use a test double instead of the real thing to verify any interactions with it.

share|improve this answer

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.

share|improve this answer

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 against MyDisposableClass.

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 that Dispose() is being called.

share|improve this answer
I don't want to test MyDisposableClass I want to mock it. Jeff Sternal and mcintyre321 bellow have good suggestions for me to try. –  Vadim Dec 23 '09 at 16:16
Nobody wants to test the using{} block. The using{} block presents a dependency that can't be injected since the instantiation of an object using the using{} block must be done In-Line. And since that dependency is typically to a persistence layer or some code that unmanaged at some point, it's important to DI it with a mock. So the question is, how do you DI a Using{} block to mock out the dependency. –  Suamere Mar 4 '14 at 23:21

Without a specification for Foo, how can we say how to test it?

  1. Get the specification for Foo.
  2. Write tests to ensure that it meets all specifications and requirements (or a reasonable subset- some functions could require practically infinite amounts of data to test).

I believe you have a second, implicit question in there - which is how to test that use of your MyDisposableClass correctly Disposes of the object when it is freed by exiting an using clause. This is a separate test issue, and shouldn't be combined with the test of Foo, since the specification of Foo shouldn't reference implementation specific details such as the use of your MyDisposabeClass.

I think the other posters have answered this question, so I won't further elaborate.

share|improve this answer

Your Answer


