Pull to refresh
50
0
Антон Сердюк @m00t

Software Engineer

Send message
Так что это только вопрос времени, когда до всех [your language]-кукумберов дойдет, что эти степы не нужны в BDD-фреймворке.
А, вот, нашел планы по удалению их в php-кукумбере тоже: https://twitter.com/BehatPHP/status/700679895316373504?lang=en
Прошу прощения, обманул насчет всех. Нашел только в оригинальном cucumber:
В целом 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
Уберите nbproject. Разделите на 2 проекта: фреймворконезависимая библиотека и драйвер к ларавелу.
Ну смотреть надо конкретно в каждом случае. Алгоритм на всё не придумаешь.
О чем постоянно твердят люди, продвигающие BDD. Сценарии это не тесты. Сценарии это способ обмена знаниями. Сценарий позволяет с бОльшей уверенностью сказать, что все участники понимают систему одинаково. Позволяют всем общаться на одном и том же языке. Автотесты это приятное дополнение.
Конкретно в этом случае я бы не писал 32 варианта, т.к. большинство из опций не влияют друг на друга. Я бы написал отдельно сценарии на конкретные опции и совместил бы где-то, где реально есть влияние. Но таблицы это тоже очень мощный и удобный инструмент задания примеров, в Gherkin они предусмотрены через Schenario Outline / Examples. Мы их активно юзаем тоже для подобных данных, где очень много примеров однотипных. Вопрос тут скорее в том, чтобы по максимуму убирать примеры, которые не интересны бизнесу. Если, например, стаж дает 10% скидку при условии включения программы поощрения, нету смысла делать 10 сценариев со стажем + программой и различными вариантами других опций, потому что знаний никаких в них не добавится, можно сделать просто несколько сценариев со стажем, программой и каким-то фиксированным набором других опций.
Можно и так сказать. Но BDD это скорее не про тестирование. Если у нас простой проект и там все понятно в требованиях, то просить BA писать эти сценарии бессмысленно — действительно, с этим лучше справятся QA. Но все меняется, когда требования сложные. Тут сценарии помогают их описывать и обсуждать намного проще, чем всякие спеки, описывающие требования. И как byproduct мы имеем пак приемочных тестов.
Если цель фичи — проверить приветствие, то можно написать
Given Я пользователь Вася Пупкин
When Я логинюсь
Then Я должен увидеть приветствие

Но приветствие это вообще не фича обычно. Я имел ввиду, что мы пишем всякие более высокоуровневые вещи типа
Я пользователь Вася Пупкин
У меня баланс $100
Я покупаю подписку
У меня баланс должен стать $50

вместо
Я нажимаю «логин»

Я нажимаю «оплатить»

Я должен увидеть $50
У нас бизнес-аналитики перестали плеваться примерно после того как мы стали писать в сценариях вместо
я нажимаю на ссылку «войти»
я ввожу «васяпупкин» в поле мыла
я ввожу «васяпупкин1111» в поле пароля
я нажимаю на кнопку «войти»
я должен увидеть «здравствуйте, Вася Пупкин!»

что-то вроде этого:
Я пользователь Вася Пупкин
А можно поинтересоваться источником этой элементарной терминологии?
Для меня первый сериал был Футурама, совершенно все понятно было еще тогда, когда я инглиш знал очень и очень плохо (если смотреть с субтитрами). Возможно, кому-то не понравится. А так да, советуют все друзей. Но футурама проще намного. Подозреваю Family Guy и симпсоны такой же уровень будут.
Почему он не подцепляет ключ, сгенерированный ssh-keygen я не знаю.

Не самая лучшая фраза, которую может сказать software developer. Лучше бы разобраться с проблемой, а не плодить костыли.
Пункты 2-3 самые прикольные у вас. Получается, программисту надо доплачивать за то, что он будет думать во время работы? И не каждый программист хочет думать во время работы? WAT??? Я всегда думал, что программист должен делать все, что в его силах в свое рабочее время, чтобы сделать работу лучше. Оказывается, нет?
Я вообще сторонник подхода, чтобы не разделять прототип и продукт. Я убежден, что прототип постепенно должен становиться продуктом по мере работы над ним. Самые кривые вещи должны постепенно рефакториться, когда они начинают доставлять неудобства. И таким образом, кривой тяп-ляп прототип постепенно должен превращаться в нормальный продукт. Мне кажется, такая эвристика в большинстве случаев подходит, если надо что-то побыструхе вывести на рынок и протестировать идею. Потому что будем честны, много ли прототипов удается переписать с нуля? Обычно этот шаг откладывается до одного большого «рефакторинга», который никогда не наступает.
Вы так недалекоглядны

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

Эммм. А я где говорил про краткосрочные vs долгосрочные? Я говорил — дешевле. Решить, дешевле на каком промежутке это должно быть — задача бизнеса, а не программиста.
Ниже отличный коммент про менеджмент vs программисты.

Вы про мой коммент ниже или про какой? =)

Information

Rating
Does not participate
Date of birth
Registered
Activity