Unit-тестирование

В концепции "Плохо", "Хорошо" и "Правильно"

Плохо если…

• Я не могу писать unit-тесты.
• Я не могу написать тест, потому что метод является статичным, или не возвращает результат, или приватный (static/void/private).
• Мои тесты выполняются слишком долго.
• Мои тесты не проходят если база данных, или web-сервис, или другая система (database/web-service/system) выключены или не доступны.

Хорошо если…

• Unit-тесты выполняются быстро (fast).
• Unit-тесты изолированы от каких-либо внешних зависимостей (isolated).
• Unit-тесты легко повторяются (repeatable).
• Unit-тесты должны быть сами себя контролировать (self-checking).
• Unit-тесты должны быть «уместными», то есть не  должны требовать много времени на поддержку работоспособности (timely).

Правильно

Если писать тесты:

• Ваш код будет покрыт «проверочным кодом».
• Вы будете знать как писать код «правильно», то есть код будет менее связанным.
• Вы упростите интеграцию нового функционала.
• Вы защищены от регрессии при написания кода.
• У вас появится дополнительная защита при публикации (CI/DC).
• Сокращается время на функциональное тестирование.
• Ваша совесть будет чиста :)

Если писать правильные тесты:

• Именование тестов: 1) имя тестируемого метода; 2) сценарий в котором выполняется тестирование; 3) ожидаемое поведение при вызове сценария
• Arrange, Act, Assert: Меньше путаницы
• Минимализм при написание тестов – признак мастерства: 1) тесты более устойчивы к изменениям; 2) ближе к тестированию поведения чем к реализации.
• Именование переменных в тестах: упрощение понимания при чтении.