В целом BDD это не совсем про тесты — это про документацию и коммуникацию, скорее. Из всех фреймворков поэтому давно поудаляли встроенные степы «я нажимаю на кнопку».
And type to input with name "userName" text: "riskmarket.testoviy2016@yandex.ru"
And type to input with name "password" text: "l0dcfJMB”
When type to input with name "lastName" text: "TESTOVIY"
And type to input with name "firstName" text: "TEST"
То, что вы делаете, считается антипаттерном в BDD. Сценарии должны быть на языке домена: Given there is user Alice
О чем постоянно твердят люди, продвигающие BDD. Сценарии это не тесты. Сценарии это способ обмена знаниями. Сценарий позволяет с бОльшей уверенностью сказать, что все участники понимают систему одинаково. Позволяют всем общаться на одном и том же языке. Автотесты это приятное дополнение.
Конкретно в этом случае я бы не писал 32 варианта, т.к. большинство из опций не влияют друг на друга. Я бы написал отдельно сценарии на конкретные опции и совместил бы где-то, где реально есть влияние. Но таблицы это тоже очень мощный и удобный инструмент задания примеров, в Gherkin они предусмотрены через Schenario Outline / Examples. Мы их активно юзаем тоже для подобных данных, где очень много примеров однотипных. Вопрос тут скорее в том, чтобы по максимуму убирать примеры, которые не интересны бизнесу. Если, например, стаж дает 10% скидку при условии включения программы поощрения, нету смысла делать 10 сценариев со стажем + программой и различными вариантами других опций, потому что знаний никаких в них не добавится, можно сделать просто несколько сценариев со стажем, программой и каким-то фиксированным набором других опций.
Можно и так сказать. Но BDD это скорее не про тестирование. Если у нас простой проект и там все понятно в требованиях, то просить BA писать эти сценарии бессмысленно — действительно, с этим лучше справятся QA. Но все меняется, когда требования сложные. Тут сценарии помогают их описывать и обсуждать намного проще, чем всякие спеки, описывающие требования. И как byproduct мы имеем пак приемочных тестов.
У нас бизнес-аналитики перестали плеваться примерно после того как мы стали писать в сценариях вместо
я нажимаю на ссылку «войти»
я ввожу «васяпупкин» в поле мыла
я ввожу «васяпупкин1111» в поле пароля
я нажимаю на кнопку «войти»
я должен увидеть «здравствуйте, Вася Пупкин!»
Для меня первый сериал был Футурама, совершенно все понятно было еще тогда, когда я инглиш знал очень и очень плохо (если смотреть с субтитрами). Возможно, кому-то не понравится. А так да, советуют все друзей. Но футурама проще намного. Подозреваю Family Guy и симпсоны такой же уровень будут.
Пункты 2-3 самые прикольные у вас. Получается, программисту надо доплачивать за то, что он будет думать во время работы? И не каждый программист хочет думать во время работы? WAT??? Я всегда думал, что программист должен делать все, что в его силах в свое рабочее время, чтобы сделать работу лучше. Оказывается, нет?
Я вообще сторонник подхода, чтобы не разделять прототип и продукт. Я убежден, что прототип постепенно должен становиться продуктом по мере работы над ним. Самые кривые вещи должны постепенно рефакториться, когда они начинают доставлять неудобства. И таким образом, кривой тяп-ляп прототип постепенно должен превращаться в нормальный продукт. Мне кажется, такая эвристика в большинстве случаев подходит, если надо что-то побыструхе вывести на рынок и протестировать идею. Потому что будем честны, много ли прототипов удается переписать с нуля? Обычно этот шаг откладывается до одного большого «рефакторинга», который никогда не наступает.
Не всегда в бизнесе преследуют только краткосрочные цели
Эммм. А я где говорил про краткосрочные vs долгосрочные? Я говорил — дешевле. Решить, дешевле на каком промежутке это должно быть — задача бизнеса, а не программиста.
То, что вы делаете, считается антипаттерном в BDD. Сценарии должны быть на языке домена:
Given there is user Alice
Но приветствие это вообще не фича обычно. Я имел ввиду, что мы пишем всякие более высокоуровневые вещи типа
вместо
что-то вроде этого:
Не самая лучшая фраза, которую может сказать software developer. Лучше бы разобраться с проблемой, а не плодить костыли.
Ну офигеть, пошел переход на личности и ярлыки.
Эммм. А я где говорил про краткосрочные vs долгосрочные? Я говорил — дешевле. Решить, дешевле на каком промежутке это должно быть — задача бизнеса, а не программиста.
Вы про мой коммент ниже или про какой? =)