Comments 3
создание сценариев имеет один серьезный недостаток - его можно использовать только в относительно небольших проектах
В общем тут можно статью заканчивать читать. На чем основано довольно ложное утверждение? Мы используем Jenkins сценарии в гигантском проекте. Никаких вообще проблем. Более того узнайте у разработчиков что такое live documentation, который они сейчас пытаются внедрять вместо юниттестов. Наши сценарии в том числе и есть спецификация функционал проекта. Да изменения бывают и часто, но это фиксируется падениями тестов и тесты легко поправить если это BDD а не код.
Если вы превращаете тестирование в программирование, то возникает логичный вопрос, а кто будет тестировать ваши тесты?
Вот именно поэтому тесты должны быть максимально декларативными и описаны человеческим языком, а не в виде кучи кода с паттернами.
Чёт как-то слишком ультимативненько и узенько. Первый же вопрос, а что в BDD не надо структурировать код, который ниже? Он типа резко становится не относящимся к тестированию? Бред...
Для структурирования кода который под BDD у вас лежит, максимум, что вам необходимо это знать один паттерн программирования: "вынеси это в отдельную процедуру". И таким волшебным способом мы избавляемся махом от ООП, Контроллеров и прочих штук, которые вносят дополнительную сложность и риск возникновения ошибок.
Подходы к организации автотестов: Чему мы можем научиться у разработчиков?