Могу ли я стремиться к TDD или BDD в моем начатом проекте?

Question

Я решил попробовать TDD и BDD в моем уже запущенном проекте, вдохновленный ответами на такие вопросы: Должен ли я начать использовать TDD в проекте, который его еще не использует

Я изо всех сил пытаюсь начать с этого. Мой проект (с открытым исходным кодом, размещенный в http://gitorious.org/rubots) похож на игру и использует Ruby для обертывания и подключения к управляющему серверу и среде физического моделирования. Сценарий выполняется, затем появляется графический интерфейс, и когда пользователь нажимает на запуск 2 внешних программы на языке c ++, одна из которых представляет собой физическое моделирование, они управляются библиотекой с привязками Ruby. Сброс симуляции и управляющей программы невозможен, их следует запустить снова. Запустите их, и их работа в рабочем состоянии займет около 5 секунд. В этом контексте любые тесты должны пройти весь начальный этап, прежде чем что-либо будет двигаться, и моделирование зависит от внешних файлов конфигурации, которые также должны быть предоставлены.

Неужели стоит начинать писать тестовые случаи? Как? Каждый тест с: before или аналогичным, который запускает игру, запускает приложения и т. Д.? Тогда каждый тест займет, по крайней мере, 5 секунд (и значительно больше, если мне придется зафиксировать команду и ждать, пока сущности симуляции ответят).

Я что-то упустил. Должен ли я пропустить не только BDD и TDD, но также и тестовые блоки для такого рода приложений?

Answer 1

На RubyConf 2007 Уильям Береза ​​(William Bereza) из Атомный объект выступил с докладом о Улучшение встраиваемой разработки с помощью Ruby , в котором он описывает, как они применяли принципы , стоящие за Атомным объектом. за (Agile, BDD, Automated Tests, ...) на внедренный проект, включающий автономные роботизированные транспортные средства. Пару месяцев назад он выступил с тем же докладом на O'Reilly OSCON 2007 .

На сайте Атомных Объектов есть множество ресурсов:

• Agile Embedded Software Development ,
• Документы ,
• Презентации и
• Свободное ПО , включая
  • SysTiR (тестирование системы в Ruby) и
  • Unity - Compact Test Framework для (встроенного) C

Существует также замечательная история об Уорде Каннингеме и TDDing встраиваемой системе, о которой Роберт Мартин («Дядя Боб») рассказал во время своего выступления на RailsConf 2009 (История примерно с 15: 50 до 17:20). История идет примерно так:

Боб приходит навестить Уорда, который отвел его в подвал, где он смотрит на маленькие круги на экране, как это самая крутая вещь во вселенной, и он взволнован, как маленький ребенок, разворачивающий свой первый велосипед на Рождество. То, что он сделал, пытался выяснить, как полностью TDD встроенное устройство (в данном случае видео конвертер) , даже не касаясь устройства вообще . Он сделал следующее: он начал писать модульный тест в JUnit, используя макет. Затем сделали этот тест и так далее, как вы обычно делаете. Затем он заменил все методы на те, которые генерировали соответствующий код сборки для устройства. Поскольку вся логика была написана (и протестирована) на Java, сами «листовые» методы были чрезвычайно простыми методами, которые выполняли только очень простые вещи, такие как «запись int в регистр» или «чтение bool из флага регистр ", для которого ассемблерный код был настолько прост, что он был" очевидно правильным ".

И, конечно же, когда он собрал свой сгенерированный код и прошил устройство, оно работало в самый первый раз, без того, чтобы он когда-либо пробовал код на устройстве, а также без того, чтобы он написал какой-либо существенный ассемблерный код.

Итак, это два подхода: в случае Atomic Object они написали программное обеспечение на C и тесты на Ruby и сгенерировали тесты из кода Ruby. В случае Уорда он написал тесты и код на Java и сгенерировал код из кода Java.

Answer 2

Это то, для чего заглушки. По сути, вы создаете Test Double , который заменяет объекты, которые обращаются к дорогостоящим услугам (как в вашем случае) или делают другие вещи. Это позволяет изолировать объект во время тестирования и ускорить выполнение тестов.

Это не только для ускорения вещей. Допустим, вы пишете некоторый код промежуточного программного обеспечения для транзакций через Paypal. Вы, вероятно, не хотите использовать сервис Paypal при выполнении тестов, что может быть дорого (буквально).

Мокко хорошо для такого рода вещей. Или просто создайте объект, который будет действовать так же, как объект вашего веб-сервиса (поскольку это Ruby, если он идет как утка ...).