Постоянное регрессионное тестирование
Чтобы безопасно изменять существующее программное обеспечение с целью рефакторинга или добавления новых функций, требуется возможность проверки, не было ли что-нибудь повреждено в процессе внесения изменений. Другими словами, требуется возможность пропуска на системе полного регрессионного теста. При обнаружении какого-либо повреждения необходимо либо его исправить, либо откатить изменения. В сообществе быстрой разработки среди программистов все более принято разрабатывать полный тестовый набор в параллель с разработкой приложения, а в действительности приверженцы быстрого подхода (агилисты, agilest) предпочитают писать код тестов до написания «настоящего» кода. Не следует ли тестировать и базу данных подобно тому, как тестируется исходный тест приложения? Внутри базы данных реализуется важная бизнес-логика в форме хранимых процедур, правил проверки корректности данных и правил ссылочной целостности (referential integrity, RI). Очевидно, что эту бизнес-логику следует тщательно тестировать.
Метод разработки, начинающийся с создания тестов (test-first development, TFD), называемый также программированием, начинающимся с создания тестов (test-first programming), является эволюционным подходом, при котором до написания нового функционального кода вы должны написать тест, который не проходит на существующем коде. Шаги TFD изображены на рис. 2 в виде диаграммы активностей UML. Разработка под управлением тестов (tеst-driven development, TDD) (Astels 2003; Beck 2003) – это комбинация TFD и рефакторинга. Сначала вы пишите код, применяя подход TFD, а когда он работает, вы обеспечиваете высокое качество разработки путем применения рефакторинга. После рефакторинга требуется снова пропустить регрессионные тесты для проверки того, что ничего не повреждено.
Рис. 2. Метод разработки, начинающийся с создания тестов
