Всем привет!

TDD конечно крутая штука в плане правильного проектирования сервиса. Правильное проектирование - имеется в виду получить публичное Java API, удобное для использования, если не с первого раза, то с меньшим количеством итераций. О плюсах TDD уже говорил тут https://t.me/javaKotlinDevOps/32 И не только я)

Но кажется есть элемент, который можно к этой технике добавить.
Перед тем, как начинать писать первый тест для еще несуществующего класса - выписать как можно больше тестовых кейсов. Не для одного метода или даже класса, а для фичи, которую надо реализовать в текущей итерации. В виде готового набора тестов это сделать сложно, т.к. кода еще нет, поэтому как комментарии.
Что там может быть:
1) входные данные -> выходные данные
2) обработка возможных исключений
3) повторный запуск: идемпотентность, докат или ошибка
4) параллельный запуск
5) поведение при различных значениях настроек
6) поведение при различных настройках кодировки, языка, часового пояса, файловой системы
7) эффекты из-за отсутствия транзакционности (там где ее нет)
...
И возможно выписывание этих кейсов приведет к изменению дизайна системы. Или к пониманию, что метод\класс\модуль имеет слишком сложную логику. Или в нем много побочных эффектов. Или что есть дублирование логики между классами, которая решается либо их объединением, либо вынесением ее в третий класс. Возможно, стоит изменить границы транзакции.

По сути это формализация процесса проектирования через запись в виде тестовых кейсов. И есть подозрение, что наличие перед глазами набора кейсов сделает процесс написания кода станет более осмысленным. И это хорошо вписывается в технику TDD.

#tdd #system_design