Точки входа в приложение тестирования TDD
Я новичок в TDD, и мне до сих пор очень нравится (хотя это процесс настройки).
Тем не менее, я борюсь с тем, как пройти тестирование точек входа в приложение. Я имею в виду main(String... args)
метод, класс, единственной обязанностью которого является загрузка и сохранение файла свойств с / на диск и т. д.
Когда я сначала делал код, это не казалось проблемой. Я просто не стал бы писать тесты для таких методов / классов. Тем не менее, как я должен следовать процессу TDD, когда есть код, который я должен написать без тестов?
Другими словами, когда / как запись точек входа вписывается в процесс разработки TDD?
1 ответ
В большинстве случаев вы не можете выполнить модульное тестирование точки входа, потому что, по определению, модульное тестирование тестирует модуль изолированно от его зависимостей.
Во всех, кроме некоторых тривиальных краевых случаях, точкой входа приложения является корень композиции, то есть место, где объединены все модули. Несмотря на то, что вы можете выполнить полный системный тест на точке входа, обычно вы должны рассматривать ее как скромный исполняемый файл.
Мое личное правило состоит в том, что исполняемый файл Humble не может содержать логику (только композицию), и я измеряю это с помощью Cyclomatic Complexity; если Cyclomatic Complexity of Humble Executable равен 1, то не стоит его проверять.
Однако, несмотря на то, что вы не можете выполнить модульное тестирование точек входа, вы все равно можете использовать внешнее TDD для управления композицией, хотя обычно вам все равно придется заменить некоторые внешние сервисы на Test Doubles.