Подход Test-Drive для гибкой разработки программного обеспечения

Сейчас часто говорят об гибкой разработке.

Что такое гибкая разработка?

Гибкая разработка  — это возможность разработки программного обеспечения, отвечающая быстро меняющимся потребностям. Их конкретные названия, концепции, процессы и терминология различаются. По сравнению с « негибкими » они подчеркивают тесное сотрудничество между командами программистов и бизнес-экспертами, общение лицом к лицу (которое считается более эффективным, чем письменная документация) и часто выпускают новые версии программного обеспечения, небольшие и  самоорганизующиеся группы  для небольших компаний . и написание ценных функций, и подходы к организации команды, которые адаптируются к меняющимся потребностям, с большим акцентом на роли людей в разработке программного обеспечения.

Однако существует несколько похожих версий методов гибкой разработки TDD, таких как TDD: BDD, DDD и ATDD. Позвольте мне кратко представить эти методы, прежде чем подробно рассказывать о TDD:

TDD: разработка через тестирование

Разработка  через тестирование (TDD) — это процесс разработки программного обеспечения, основанный на преобразовании требований к программному обеспечению в тестовые сценарии до того, как программное обеспечение будет полностью разработано, и на отслеживании всей разработки программного обеспечения путем многократного тестирования программного обеспечения для всех тестовых случаев. Это противоположно сначала разработке программного обеспечения, а затем созданию тестовых случаев. Некоторые популярные модели очень хорошо поддерживают TDD, например MVC и  MVP .

BDD: Behavior Driven Development (Разработка, управляемая поведением)

Разработка, управляемая поведением (BDD), также является гибким процессом разработки программного обеспечения. Он поощряет сотрудничество между разработчиками, тестировщиками обеспечения качества и представителями клиентов в проектах программного обеспечения. Он побуждает команды использовать обсуждения и конкретные примеры для формализации общего понимания того, как должно работать приложение. Это происходит из разработки через тестирование (TDD).

ATDD: разработка, основанная на приемочных испытаниях

Чтобы способствовать реализации функционального кода с помощью модульных тестов, команда должна определить ожидаемые стандарты качества и правила приемки, а также продвигать практику TDD разработчиков и производительность тестировщиков с помощью четкого и последовательного плана приемочного тестирования (включая серию тестов). сценарии). Для разработчиков это подчеркивает, как внедрить систему и как ее протестировать.

DDD: Дизайн доменного диска

DDD относится к проектированию, управляемому предметной областью, т.е. разработке, ориентированной на предметную область. DDD фактически построен на этом фундаменте, потому что он фокусируется на проектировании сервисного уровня, фокусируется на бизнес-реализации, сочетает аналитику и дизайн и больше не держит его в разделенном состоянии, чтобы правильно и всесторонне реализовать потребности клиентов и построить модель бизнеса. масштабируемость.

План реализации TDD

Через тестирование для продвижения всей разработки, но разработка через тестирование — это не просто тестовые работы, а процесс количественного анализа требований, проектирования и контроля качества.

Принципы разработки

Сначала напишите тестовый код, а затем напишите код функции.

1. Напишите тестовый код в соответствии с документом требований, а не для реализации функции;
2. Не хочу быть толстой с одного укуса. При тестировании больших функциональных блоков вы должны сначала разделить их на более мелкие функциональные блоки для тестирования;
3. Помните, что не нужно писать код для завершения функции, используйте максимально простой код для реализации функции;
4. Если требования можно протестировать, напишите тестовый код и откажитесь от тех, которые невозможно протестировать или которые не нуждаются в тестировании;
5. Прежде чем изменять/добавлять какой-либо код функции, вы должны сначала подумать о том, хотите ли вы изменить/добавить тестовые примеры;
6. Код функции/теста, неразумная структура, повторяющийся код и т. д. рефакторинг во времени после прохождения теста.

Процесс разработки TDD

1. Проанализировать и определить целевой тестовый сценарий;
2. Добавьте модульный тест для проверки ввода и вывода тестового сценария;
3. Запустите тест и получите результат неудачного теста;
4. Напишите простейший код функции, чтобы пройти тест;
5. Запустите тест еще раз и убедитесь, что тест проходит успешно;
6. Провести рефакторинг кода, включая функциональный код и код модульного тестирования;
7. Повторяйте вышеуказанные шаги, пока разработка не будет завершена.

Преимущества TDD

1. Снизить нагрузку на разработчиков . Благодаря четкому процессу давайте сосредоточимся только на одной точке за раз, и нагрузка на размышления уменьшится.
2. Сетка защиты . Полное модульное тестирование обеспечивает защитную сетку для кода продукта, позволяя легко реагировать на изменения в требованиях или улучшать дизайн кода. Так что, если требования вашего проекта стабильны, выполняются сразу и последующих изменений нет, преимущества TDD меньше.
3. Заранее уточняйте требования . Сначала написание тестов может помочь нам подумать о требованиях и заранее прояснить детали требований, а не обнаруживать неясные требования только на полпути к коду.
4. Быстрая обратная связь . Многие говорят, что при TDD объем моего кода увеличивается, поэтому эффективность разработки снижается. Однако, если у вас нет модульных тестов, вам придется тестировать их вручную, вы тратите много времени на подготовку данных, запуск приложений, изменение интерфейсов и т. д., а обратная связь происходит медленно. Чтобы быть точным, быстрая обратная связь является преимуществом модульного тестирования.