Можно ли утверждать, что метод был вызван в модульном тестировании VS2005?

Question

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

* 1003 Е.Г. *

 String testValue = "1234";
 MyClass target = new MyClass();
 target.Value = testValue;

 target.RunConversion();

 // required Assertion
 Assert.MethodCalled(MyClass.RunSpecificConversion);

Затем будет второй тест, в котором testValue будет нулевым, и я бы хотел сказать, что метод НЕ был вызван.

---

Обновление для конкретного тестового сценария:

У меня есть класс, представляющий информацию, десериализованную из XML. Этот класс содержит ряд информации, которую мне нужно преобразовать в свои собственные классы.

Класс XML - это информация о человеке, включая информацию об учетной записи и несколько телефонных номеров в разных полях.

У меня есть метод для создания моего класса Account из класса XML и методы для создания правильных классов телефона из класса XML. У меня есть модульные тесты для каждого из этих методов, но я хотел бы проверить, что, когда вызывается преобразование учетной записи, он запускает телефонные преобразования, поскольку результаты фактически являются свойствами класса учетной записи.

Я знаю, что смогу проверить свойства класса аккаунта после ввода правильной информации, однако у меня есть другие вложенные свойства, которые в дальнейшем будут вложены, и тестирование всего дерева может стать очень громоздким. Полагаю, я мог бы просто проверить каждый уровень на следующем уровне ниже его, но в идеале я хотел бы убедиться, что вызываются правильные методы convino, и код не дублируется в реализации.

Answer 1

Другая перспектива - вы можете быть юнит-тестированием на слишком низком уровне, что может сделать ваши тесты хрупкими.

Как правило, лучше тестировать бизнес-требования, чем детали реализации. например вы запускаете преобразование с «1234» в качестве входа, и преобразование должно инвертировать вход, так что вы ожидаете «4321» в качестве выхода.

Не проверяйте, что вы ожидаете, что "1234" будет конвертировано определенной последовательностью шагов. В будущем вы можете изменить детали реализации, тогда проверка не будет выполнена, даже если бизнес-требования все еще выполняются.

Конечно, ваш тест в вопросе может быть реальным бизнес-требованием, и в этом случае оно будет правильным.

Другой случай, когда вы захотите это сделать, - это если вызов преобразования в реальном MyClass не подходит для модульного теста, т. Е. Требует большой настройки или требует много времени. Тогда вам нужно будет издеваться или заглушить его.

---

Ответ на вопрос edit:

Исходя из вашего сценария, я все равно был бы склонен проверять, проверяя вывод, а не проверять, были ли вызваны определенные методы.

У вас могут быть тесты с различными входными данными XML, чтобы гарантировать, что для прохождения тестов нужно будет вызывать разные методы преобразования.

И я бы не стал полагаться на тесты для проверки наличия дублирующегося кода, а скорее рефакторизовал бы удаление дубликата кода, когда натолкнулся на него, и просто полагался на модульные тесты, чтобы гарантировать, что код все еще выполняет ту же функцию после рефакторинга.

Answer 2

Без использования инфраструктуры Mocking, такой как Moq, TypeMock, RhinoMocks, которая может подтвердить ваши ожидания, я бы посмотрел на анализ трассировки стека.

Документация MSDN ее е должна помочь.

Доброжелательность,

Dan

Answer 3

Вы хотите исследовать использование фальшивых фреймворков.

Или вы можете создавать свои собственные поддельные объекты для записи звонков. Вам нужно будет создать интерфейс, который реализует класс.

Один из способов создания подделок, который я видел, выглядит следующим образом:

interface MyInterface
{
    void Method();
}

// Real class
class MyClass : MyInterface
{
}

// Fake class for recording calls
class FakeMyClass : MyInterface
{
    public bool MethodCalled;
    public void Method()
    {
        this.MethodCalled = true;
    }
}

Затем вам нужно использовать какое-то внедрение зависимостей, чтобы использовать этот поддельный класс вместо реального при выполнении тестов.

Конечно, проблема в том, что класс Fake будет записывать только вызовы методов, но не будет делать ничего реального. Это не всегда будет применимо. Работает нормально в среде Model-View-Presenter.

Answer 4

Вы можете использовать фреймворк, такой как Rhino Mocks или moq Для этого вы также можете использовать инфраструктуру изоляции, например Isolator .

Другой вариант - унаследовать класс, по которому вы хотите проверить, и поднять внутри него флаг, по которому был вызван метод. Вместо утверждения в вашем тесте утверждать против флага. (в основном это насмешка с ручным управлением)

Пример использования Isolator:

Isolate.Verify.WasCalledWithAnyArguments(() => target.RunSpecificConversion());

Отказ от ответственности - я работаю в Typemock