How to unit test a method with a `using` statement

2019-02-06 08:17发布

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.

7条回答
Evening l夕情丶
2楼-- · 2019-02-06 08:28

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.

查看更多
冷血范
3楼-- · 2019-02-06 08:31

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.

public bool Foo()
{
    using (IMyDisposableClass client = _myDisposableClassFactory.Create())
    {
        return client.SomeOtherMethod();
    }
}
查看更多
兄弟一词,经得起流年.
4楼-- · 2019-02-06 08:33

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.

查看更多
5楼-- · 2019-02-06 08:35

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

查看更多
老娘就宠你
6楼-- · 2019-02-06 08:42

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

[TestFixture]
public class When_calling_Foo
{
    [Test]
    public void Should_call_Dispose()
    {
        IMyDisposableClass disposable = MockRepository
                                        .GenerateMock<IMyDisposableClass>();

        Stuff stuff = new Stuff(disposable);

        stuff.Foo();

        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();
}
查看更多
劳资没心,怎么记你
7楼-- · 2019-02-06 08:51

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.

查看更多
登录 后发表回答