Cucumber и BDD. Пишем UI-автотесты на iOS

[azzas]

Лично для меня Кукумбер всегда был загадкой: для кого он?

Разрабы тестов будут писать новые тесты в BDD? Серьезно?

Тестировщики будут писать в BDD, не зная как реализованы методы? А если тестировщики смотрят в код, то проще четко вызывать методы с параметрами. Не будет блэкбоксов — я вызвал этот тест на «человеческом» языке, он прошел корректно, но фиг знает что там отработало.

Хотя может я просто не видел классной реализации таких тестов.

[ser_ivor]

Разрабы тестов будут писать новые тесты в BDD? Серьезно?

Да, автотестеры пишут фичи, степы и их интерпритации)) Почему это Вас так удивило?

Тестировщики будут писать в BDD, не зная как реализованы методы?

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

Лично для меня Кукумбер всегда был загадкой: для кого он?

Его прелесто заключается в том, что с помощью языка Gherkin можно легко описать любой бизнес-процесс (читай: новый requirement), показать отчёт выполнения теста аналитику и он поймёт что к чему.
Однако это не отменяет тот факт, что это дополнительный слой разработки, что отнимает время

[crowCcrow]

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

[m_aleksei]

Для меня всегда BDD был больше преградой при написании 500+ тестов. Слишком много надо писать этих условий. Каждый норовит дать свое названия. Легко дуплятся. Это все значительно усложняет поддержку. Может только у меня?

[belQa]

Все зависит от того, какой у вас процесс в автоматизации: кто и как пишет сценарии, кто реализуем шаги, что идет сначала — реализация или сценарий (правильно написал crowCcrow в ответе к предыдущему комменту про проблему забивания на идею проверки).

Имхо, BDD действительно не всегда нужен, не всем он подходит. Но если проблема в удобстве именно использования инструмента (aka сложно поддерживать, много путаницы со сценариями), а не подхода в целом, то сам BDD-подход, стало быть, тут не при чем. Возможно, стоит поискать проблемы в том, как именно используется инструмент :)

[mnkuzin]

предполагаю что подход будет особенно актуален при разработке через тдд, когда 500+ тестов были написаны вышестоящим типом, а потом сама задача отдана на искупление армии джунов

[Loki1941]

Спасибо за статью, очень просто и понятно расписано!