Написание тестов и крепкие нервы

Написание тестов - это не просто доказательство того, что код работает правильно. Это отдельный вид творчества, который рассказывает о функциональности, о том, как «это» работает и что можно получить в итоге. По сути, это вторая документация.

Тесты могут причинить немало хлопот, если нет систематизированного подхода к их написанию. Самый нашумевший из них – TDD.

TDD (Test-Driven Development)

Разработка через тестирование - этот подход имеет как минимум пару особенностей:

• Тесты пишутся до написания кода. Потом обеспечивается их прохождение и рефакторинг кода. И так по кругу.

• Не так легко сходу начать применять его, особенно, когда над ухом слышишь, как спрашивает бизнес: «Ну что, готово?». Нужна практика и время.

Моя стратегия написания тестов, обычно, сводится к следующим двум подходам (аббревиатура из головы):

БКТ (блок кода, тест)

Использую чаще всего. Он не заставляет судорожно бегать по коду и анализировать, все ли кейсы были учтены. Минус в том, что написанное может не пригодится в итоге. Стирается код, удаляются тесты. Как итог - выкинутое в мусорку время.

ВКТ (весь код, тесты)

Сначала пишется код, потом ищутся случаи, которые нужно протестировать. Благо, если заранее, в тестовом классе, были описаны ветвления тестирования с комментариями, типа:

// API (Контроллер)
  // Запрос на получение данных
    // запрос пустой
      // ок – вернуть все данные
	// иначе
      // проверить корректность полученных данных
         // корректно – вернуть данные
      	 // иначе – сообщить об ошибке
…
// Сервис (бизнес-логика)
…
// Инфраструктурный слой (получение данных из другого сервиса, бд и пр.)
…

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

А какие подходы к тестированию применяете вы?