А что конкретно Вас раздражает в огурце? Его недостатки я вижу. Но разве та ситуация с которой я тут начал эту дискуссию, связана с проблемой огурца?

Нет-нет, сменить огурец предложила не я, я только всеми лапами поддержала))
Но конкретно в вашей ситуации *возможно* отсутствие огурца поможет добавить действия-на-fail без вальса с бубнами)

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

Вот вам решение под огурец

Вообще, когда видишь в bdd сценариях множество And .... Уже понятно что bdd мешает.

почему? если после получения страницы вам нужно проверить 5 независимых друг от друга результата, как вы предлагаете их оформить?

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

Да с этим соглашусь.

В этом и есть основная проблема - прослойку добавляет, плюшки языка отбирает)

Спасибо,

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

Мы ж всем чатом не настаиваем х) Просто высказываем наболевшее мнение и сочувствуем))

Буду рад получится ссылку

в гугле-то? Всяко

Потому что такой сценарий уже превращается в программу. Два, ну пускай три "и" ещё куда ни шло. Но 5 - уже имеет смысл убрать в шаг, который будет проверять их все.

но ведь если вы спрячете "я проверяю А" и "я проверяю Б" и ... "я проверяю Щ" за "я проверяю комплекс значений", то вы теряете силу Кукумбера - возможность писания тестов бизнес людьми, которые как раз эти проверки и напишут.

Большинство бизнес-людей как раз и пишут "комплекс" а не расписывают каждый )
Никто не говорит что так нельзя писать. Но Если у вас много такого - быть может стоит разнести проверки по разным тестам?
Не нашёл оригинального подкаста, нашёл транскипт. Посмотрите Multiple Then ..
http://www.thinkcode.se/blog/2016/06/22/cucumber-antipatterns

Разбить на несколько тестов будет полезнее, в случае если у вас проверяется в одном тесте несколько важных бизнесу вещей, то в случае падения теста на первой проверке - вы уже не узнаете состояние остальных.

спасибо, обязательно гляну. Собственно, я постепенно мигрирую в ту сторону, что вы сказали, но изначальный подход, который учитывал мнение мануальных товарищей был именно такой: у вас есть итоговые данные, в данном случае xml и нужно проверить 3-4 значения в различных тэгах.  Были несколько and и в каждом степе написано какой тэг проверять и что в нем должно было быть.  В целом работало.

Всем привет. Подскажите как изменить одно поле в стабах json?