Прагматичное юнит-тестирование

Для не знающих

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

Но

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

• Рефакторинг. Улучшение существующего кода
• Экстремальное программирование: разработка через тестирование
• Шаблоны тестирования xUnit. Рефакторинг кода тестов — эта книга мега-лекарство.

Для знающих много пользы

А знать надо вот что:

• Юнит-тест — тестирует лишь небольшой кусочек функционала.
  В идеале протестировать метод на то, что он правильно делает вызовы других методов
• Юнит-тест невероятно быстр.
  Поскольку тестируется лишь маленький кусочек функционала без обращений к бд или файлам — все довольно таки быстро.
• Для большого метода юнит-тест написать очень сложно.
  Сложно, потому что много логики. Приходится слишком много заглушек делать для одного метода.
• Тестируемый функционал не обращается к базе данных, не отправляет запросов, не считывает файлы с диска.
  Это долго и тестируемый функционал становится незащищенным от сбоев внешнего функционала.
• Юнит-тест не зависит не от порядка выполнения теста, не от сбоев в остальном функционале.
  Тесты должны быть независимы — это упрощает локализацию ошибок.
• Все юнит-тесты вместе взятые выполняются не более 10 секунд в любом проекте.
  Иначе слишком часто запускать их будет не удобно.
• Юнит-тесты как и код требуют рефакторинга.
  Постоянно делая рефакторинг, получите свой тестовый язык (или апи) для тестов.
• 100% покрытие юнит-тестами не даст 100% гарантии работоспособности проекта.
  Всего не учтешь и не протестируешь.

Тесты дадут возможность:
• избежать сценариев — кто похерил мой функционал? (разработчик); как же так, оно ведь уже работало? (заказчик)
• смело делать рефакторинг кода, который используется во всем проекте
• быстро находить ошибки
• получать удовольствие от разработки (когда знаешь, что все работает — очень хорошее чувство)

Еще мысли

Разработка через тестирование? — В идеале.

Легко тестировать функционал для рассчетов чего-либо — это сплошное удовольствие.

Являются ли тесты гарантией успеха проекта? — Нет, также как и хороший код. Но приятнее работать с хорошим кодом и с протестированным функционалом.

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

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

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

И обязательно прочтите книги из списка, если еще этого не сделали.