Что тестировать в модульном тестировании, метод или сценарий? - PullRequest
1 голос
/ 20 апреля 2009

Что тестировать в модульном тестировании, метод или сценарий?

Если тестировать каждый метод, тогда требуется минимальная настройка тестового набора.

Если тестировать метод, который вызывает другие методы, то настройка, необходимая для тестового примера, огромна Если юнит-тесты для отдельных методов уже существуют, зачем писать для этого метода, который их использует?

Но тогда у него также есть немного функциональности, которая должна быть проверена. Также инструмент покрытия кода будет жаловаться на процент покрытия.

Пожалуйста, укажите ваши практические данные.

Ответы [ 3 ]

3 голосов
/ 20 апреля 2009

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

Поскольку этот метод может вызывать лежащие в основе методы с неправильным параметром или в неправильной последовательности, или делать неправильные действия с возвращаемыми значениями.

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

«Классические» модульные тесты, где вы полностью тестируете поведение каждого класса в отдельности, являются хорошей концепцией, но в действительности этот сценарий не так уж распространен или полезен. Это зависит от того, сколько усилий было уделено разработке кода для модульности и (подразумевается в этом) тестируемости, но достичь этого никогда не удастся.

2 голосов
/ 21 апреля 2009

Правило номер один модульного тестирования:

Одновременно проверяйте только одну вещь!

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

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

2 голосов
/ 20 апреля 2009

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

Типичной структурой юнит-теста является Arrange-Act-assert (triple A's):

  • Arrange - создайте среду для случая, который вы хотите протестировать (это можно сделать в настройках Suite или в TestCase, или в обоих) *
  • Act - тестовый случай вызывает тестируемый метод
  • Утверждение - чтобы проверить, что тестируемый метод сделал то, что он должен делать

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

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

...