Comments 19
Хотел написать, что юнит тесты нужны даже если приложение пишет один человек и он всегда будет один, потому что они продемонстрируют ему, что он сломал код до того, как это узнают пользователи. Но тут понял, что вопрос шире. Тесты надо писать до всего остального — это ускоряет разработку и улучшает качество кода, и об этом в статье вообще ничего не сказано.
Ну как же не сказано? Вот, в самом начале:
Ни один разработчик в здравом уме и трезвой памяти при разработке сложных приложений (> 100K LOC, например) не станет отрицать необходимость использования тестирования вообще и модульного тестирования (unit tests) в частности.
Если рассуждать с точки зрения TDD, то вы совершенно правы.
А вы пробовали DUnit? Да, он давно не менялся, но и Delphi не вчера родилось. Может вполне юзабельно окажется.
Если я правильно понимаю, то вы используете предопределенные компоненты в качестве базовых, создаете на их основе собственные, которые связываете мышкой и немножко с клавиатуры. Полагаем, что предопределенные компоненты уже оттестированы, и нам их тестировать нет нужды. Значит нужно протестировать заданные свойства вновь созданных компонентов их связи между собой. Вряд ли легковесный CppUnit встроен с C++ Builder настолько, что все можно сделать также мышкой, поэтому придется делать ручками с клавиатуры. Т.к. для строительства приложения вы используете компоненты, то unit-тестирование — самое то. Мокируем окружение, создаем собственную компоненту и проверяем те свойства, которые мы напрограммировали для этой компоненты мышкой и с клавы. Главный вопрос — есть ли подходящая билиотека для создания моков? Сообщество говорит, что есть opmock. Сам я подобных связок не пробовал, но начал бы копать с этого.
всё работает без единой строчки кода.
подозреваю, что если как следует поискать в файлах проекта, то все-таки код можно будет обнаружить :)
и еще такой момент, коллега — судя по вашему описанию, вы широко используете возможности по генерации кода, предоставляемые средой. Тестовый код по отношению к тестируемому идет как 1:2/3/4… (в зависимости от сложности логики тестируемого кода). Если вы до сих пор не столкнулись с удобным инструментом для автоматической генерации unit-тестов в своей среде, то вряд ли он существует. Захотите ли вы вручную создавать тесты для того кода, который нагенерит ваша среда? Посчитайте LOC вашего проекта и умножьте его на 2, для начала.
"Визуальное программирование" в среде builder'а подразумевает автоматическую генерацию кода на выходе (для каждого фрейма и так три файла — h,cpp,dfm). Если продолжать данную традицию, то можно ожидать, что также возможно создание соответствующего unit-теста (*_Test.cpp или что-то подобное) для каждого компонента, в том же автоматическом режиме. Я сам с таким не сталкивался, но допускаю, что если можно сгенерировать по шаблону некий код, то можно сгенерировать и unit-тест для него.
Я имел в виду, что если просто делать копии рабочих исходников (например, с расширением .orig), то по ним точно так же можно отслеживать изменения кода в рабочих исходниках, как и при использовании мокирования для тестирования кода содержащего линейную последовательность действий. Вот только можно не писать юнит-тест для такого класса, а просто брать эталонный исходник, подписывать его "сениорской" пописью и проверять, что "джуниор" не запорол код при рефакторинге. Абсурд, в общем, тут имелся в виду.
Да, так и есть. Если очень сильно применять SRP, то начинают попадаться классы, мокать которые при тестировании — полная ерунда. Коллега Dimitar Ginev как раз и рекомендует не заниматься ерундой и не тестировать подобные классы (orchestrators).
Unit-тестирование в сложных приложениях