Уровень домена и BDD

Да, мы обнаружили, что этот процесс работает очень хорошо, и использовали specflow для довольно простой реализации этого подхода. У нас есть более 2000+ сценариев, реализованных только на нашем доменном уровне, и мы также использовали этот подход для тестирования наших контроллеров на нашем уровне пользовательского интерфейса (еще 2000+ тестов).

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

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

Да, хотя в последнее время мы рассматриваем Cuke и Specification by Example как более высокий уровень, с которого можно начать движение. См. http://specificationbyexample.com/.

Да, для этого он и нужен!

Я обнаружил, что основные преимущества BDD заключаются в том, что он естественным образом позволяет вам;

1. Управляйте дизайном (планируйте, затем делайте)

2. Откройте для себя и подчеркните вездесущий язык доменов

3. Документируйте ход проекта и текущее состояние (спецификации сопоставляются с историями и планами спринтов)

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

Я также согласен с ранее упомянутыми проблемами «дублирования шагов», это хорошо потраченное время на рефакторинг и объединение шагов, пытаясь сохранить их хорошо структурированными.