Я был в многочисленных командах, которые пытаются практиковать гибкие методологии, и часто эти команды ориентированы на тестирование. Является ли тестирование необходимой частью практики Agile-методологии, или это просто практика XP, которая используется на протяжении многих лет?

Тестирование абсолютно необходимо для agile, в первую очередь потому, что agile основан на постепенных улучшениях: сложность в том, что иногда бывает трудно увидеть, как текущие изменения повлияют на ваш старый код. Лучший способ быть уверенным в том, что вы что-то не сломали, - это проверить и узнать, КАК это проверить. Таким образом, вы сразу же обнаружите ошибку, а не в будущем, когда вы точно забыли, что делали, когда писали код, который сломал какую-то старую функцию.

Причина, по которой это отличается от более традиционного программирования типа сверху вниз, заключается в том, что в такой среде его а) очень сложно тестировать, пока у вас не будет готового продукта; б) теоретически вы рассматриваете все критерии проектирования одновременно, и таким образом, вы с меньшей вероятностью примете проектное решение, которое нарушит предыдущие проектные решения.

Вы, вероятно, говорите об автоматизированном тестировании, модульных тестах, интеграционных тестах и ​​т. Д. Они более важны для гибкого тестирования, чем ручное тестирование (с тестерами и т. П.), Поскольку они слишком медленные, поэтому невозможно проверить каждое небольшое изменение, которое вы вносите. Поскольку agile - это быстрые небольшие итерации, очень полезно иметь тесты, которые проверяют правильность в секундах или минутах, а не часах или днях.

Если у вас нет тестов, как вы узнаете, как работает ваш код?

Редактировать: утверждение, что тесты не могут доказать, что код работает, не может определить один важный термин, а именно работает . Что значит для программы работать? Если вы оставите этот термин расплывчатым, то нет никакого способа доказать или убедиться, что любая программа работает. Когда-либо.

С другой стороны, вы можете определить работы как «ведет себя в соответствии со спецификацией». Теперь вы можете не только использовать тесты, чтобы показать, что код работает, но сами тесты могут служить исполняемой спецификацией поведения вашего кода. Другими словами, хорошо написанный набор тестов определяет, что значит работать .

Этот способ мышления также заставляет вас пересмотреть значение ошибки . Если ваш код проходит все тесты, то в коде нет ошибок. Если, несмотря на это, система ведет себя не так, как должна, ее поведение указывается неправильно. И. е. ошибка в спецификации, определенной тестами.

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

Нет, это не «необходимо»

В принципах Agile ничего не говорят непосредственно о тестировании.

Но это очень желательно

Учитывая приверженность Agile устойчивому процессу, непрерывной / поэтапной доставке и качеству программного обеспечения, автоматизированное тестирование является лучшим решением, доступным в настоящее время для большинства проектов.

Исключения (как отметил Йорг В. Миттаг) включают в себя корректно доказуемые средства разработки, системы метапрограммирования, генерирующие код, и др. Но такого рода системы встречаются редко.

И Agile, и XP стараются избегать Big Design Up Front . В BDUF требования собираются, создается формальная спецификация, затем выполняется кодирование, затем проводится тестирование. Это имеет смысл для четко определенных, критически важных и жизненно важных систем, таких как медицинское оборудование, космические зонды и т. Д.

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

Автоматизированные модульные тесты быстро пишутся, быстро запускаются и очень модульны / отделены. Это делает их быстрым способом формально определить и проверить требования.