У меня есть класс API, который имеет полное покрытие кода и использует DI для насмешки всей логики в основной функции класса (Job. Выполненный), который делает всю работу.
Я нашел ошибку в производстве, где мы не делали некоторой проверки на одном из полей ввода данных.
Так, я добавил интерфейсную функцию под названием ValidateFoo ()... Записал модульный тест против этой функции для Ожидания JobFailedException, запустил тест - это перестало работать, очевидно, потому что та функция была пуста. Я добавил логику проверки и теперь тестовые передачи.
Большой, теперь мы знаем работы проверки. Проблема - как я пишу тест, чтобы удостовериться, что ValidateFoo () на самом деле называют в Job. Выполненный ()? ValidateFoo () является закрытым методом класса Job - таким образом, это не интерфейс...
Там должен так или иначе сделать это с NMock2.0? Я знаю, что TypeMock поддерживает фальшивки не интерфейсные типы. Но изменение насмешки освобождает, прямо сейчас не опция. В этой точке, если NMock не может поддерживать его, я просто просто добавлю, что ValidateFoo () называют к Выполнению () метод и тестируют вещи вручную - который, очевидно, я предпочел бы не делать рассмотрение моего Job. Выполненный () метод имеет 100%-е покрытие прямо сейчас. Совет? Спасибо очень это ценится.
Править: другая опция, которую я имею в виду, состоит в том, чтобы просто создать интеграционный тест на моего Job. Выполненная функциональность (вводящий к нему истинные реализации составных объектов вместо насмешек). Я дам ему плохое входное значение для того поля и затем проверю это отказавшее задание. Это работает и покрывает мой тест - но это не действительно модульный тест, но вместо этого интеграционный тест, который тестирует одну единицу функциональности.... хм..
EDIT2: там какой-либо путь состоит в том, чтобы сделать tihs? У кого-либо есть идеи? Возможно, TypeMock - или лучший дизайн?
Текущая версия NMock2 может имитировать конкретные типы (я не помню, в какой именно версии они были добавлены, но мы используем версию 2.1 ) с использованием в основном знакомого синтаксиса:
Job job = mockery.NewMock<Job>(MockStyle.Transparent);
Stub.On(job).Method("ValidateFoo").Will(Return.Value(true));
MockStyle.Transparent указывает, что все, что вы не заглушаете и не ожидаете, должно обрабатываться базовой реализацией, поэтому вы можете заглушить и установить ожидания для методов в экземпляре, который вы тестируете.
Однако вы можете ограничивать и устанавливать ожидания только для общедоступных методов (и свойств), которые также должны быть виртуальными или абстрактными. Итак, чтобы не полагаться на интеграционное тестирование, у вас есть два варианта:
Job.ValidateFoo ()
общедоступным и виртуальным. Job
.