Как выполнить тестирование метода с помощью инструкции `using`?

Question

Как написать единичный тест для метода, который использует инструкцию using?

Например, допустим, что у меня есть метод Foo.

public bool Foo() 
{ 
    using (IMyDisposableClass client = new MyDisposableClass()) 
    { 
     return client.SomeOtherMethod(); 
    } 
} 

Как я могу проверить что-то вроде кода выше?

Иногда я предпочитаю не использовать инструкцию using и Dispose() объект вручную. Я надеюсь, что кто-то покажет мне трюк, который я могу использовать.

Answer 1

Если вы построили IMyDisposableClass с использованием фабрики (введенной в родительский класс), а не с помощью нового ключевого слова, вы можете высмеять IMyDisposable и выполнить проверку вызова метода dispose.

Answer 2

Методы обертки, подобные этому, не подлежат тестированию, поскольку вы не можете указать соответствующие предварительные условия или пост-условия.

Для того, чтобы метод проверяемым, вам придется пройти IMyDisposableClass экземпляр в метод или в классе хостинг Foo (и сделать сам хозяин класс реализации IDisposable), так что вы можете использовать тест двойной вместо реального чтобы проверить любые взаимодействия с ним.

Answer 3

Если вы тестируете Foo, то вы должны смотреть на выход Foo, не беспокоясь об утилизации класса, который он использует внутри.

Если вы хотите протестировать метод MyDisposableClass 'dispose, чтобы проверить, не работает ли он, это должен быть отдельный модульный тест, построенный против MyDisposableClass.

Вам не нужно тестировать блок using { }, так как это часть языка. Вы либо верите, что он работает, либо не используете C#. :) Я не вижу необходимости писать модульный тест, чтобы убедиться, что вызывается Dispose().

Answer 4

Если у вас уже есть код и вы спрашиваете, как его протестировать, вы сначала не пишете свои тесты ... так что на самом деле не делаете TDD.

Однако у вас есть зависимость. Таким образом, подход TDD состоял бы в использовании Dependency Injection. Это можно сделать проще с помощью контейнера IoC, например Unity.

При выполнении TDD «правильно», ваши мыслительные процессы должны работать следующим образом в этом виде сценария:

• мне нужно сделать Foo
• Для этого я буду опираться на внешнюю зависимость, которая будет реализовать интерфейс (новый или уже существующий) из IMyDisposableClass
• Поэтому я инжектировать IMyDisposableClass в класс, в котором Foo объявляется с помощью своего конструктора

Затем вы должны написать один (или более) тесты, которые не пройдут, и только тогда вы были бы в том месте, где вы писали тело функции Foo, и определить, нужно ли вам использовать блок using.

В действительности вы вполне можете знать, что да, вы будете использовать блок using. Но часть точки TDD заключается в том, что вам не нужно беспокоиться об этом, пока не доказали (через тесты), что вам нужно использовать объект, который этого требует.

После того, как вы определили, что вам нужно использовать using блок вы бы тогда хотите написать тест, который не - например, используя что-то вроде Rhino Mocks установить ожидание того, что Dispose будет вызван на макете объекта, который реализует IMyDisposableClass ,

Например (используя Rhino Mocks для издевки 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()); 
    } 
} 

Класс, в котором существует ваша функция Foo, с IMyDisposableClass впрыскивается как зависимость:

public class Stuff 
{ 
    private readonly IMyDisposableClass _client; 

    public Stuff(IMyDisposableClass client) 
    { 
     _client = client; 
    } 

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

И интерфейс IMyDisposableClass

public interface IMyDisposableClass : IDisposable 
{ 
    bool SomeOtherMethod(); 
} 

Answer 5

Ваш вопрос не имеет смысла. Если вы используете TDD, у вас уже должен быть тест на то, что вы написали. Требования, затем тесты, затем дизайн, затем развитие. Либо ваш код проходит ваши тесты, либо нет.

Теперь, если ваш вопрос заключается в том, как выполнить тестирование вышеприведенного кода, тогда это еще один вопрос, и я думаю, что другие плакаты ответили на него.

Иногда я думаю, что есть больше, чем словечки разработчиков :)

Answer 6

Ваш вопрос не имеет смысла. Если вы делаете TDD, то метод, который вы опубликовали, уже уже прошел, в противном случае он даже не мог существовать. Итак, ваш вопрос не имеет смысла.

Если, с другой стороны, метод, который вы опубликовали, уже существует, но не полностью протестирован, то вы все равно не делаете TDD, и ваш вопрос о TDD тоже не имеет смысла.

В TDD просто невозможно для непроверенного кода. Период.

Answer 7

Без спецификации Foo, как мы можем сказать, как ее проверить?

1. Получить спецификации для Foo.
2. Напишите тесты для обеспечения соответствия всех спецификаций и требований (или для разумных подмножеств некоторых функций может потребоваться практически бесконечное количество данных для тестирования).

Я считаю, что у вас есть второй, неявный вопрос, - вот как проверить правильность использования вашего MyDisposableClass. Выделяет объект, когда он освобождается, выходя из предложения use. Это отдельная тестовая проблема и не должна сочетаться с тестом Foo, поскольку спецификация Foo не должна ссылаться на конкретные данные конкретной реализации, такие как использование вашего MyDisposabeClass.

Я думаю, что другие плакаты ответили на этот вопрос, поэтому я не буду более подробно разбираться.