Если я правильно понял вопрос - "что будет, если не использовать фреймворк masquerade, и пользоваться selenium для автоматизации CUBA проектов (или вообще)?", то ответ - суть не изменится, просто на разработку и поддержание тестов нужно будет закладывать больше времени, что имеет свои последствия - бюджет и целесообразность. Можно использовать BDD и на чистом Selenium без всяких селенидов и других библиотек, но без упрощения разработки и поддержки тестов все эти начинания часто теряют смысл.
По моему опыту в ВУЗе в разы меньше неадеквата, чем в школе. Туда идут более адекватные люди, да еще и со схожими интересами, а не как в школе от звонка до звонка и гори оно все огнем. Поэтому, мне кажется, нет смысла переживать о переходе на очку в ВУЗ/колледж или что-то подобное
Изначально инициатива использования BDD шла от зарубежного заказчика, поэтому было немного проще. Сейчас мы пробуем использование на другом проекте, но тут уже есть интерес у наших аналитиков. Сложность заключается в том «как писать?», поэтому первая задача в данном случае правильно назвать шаги, что бы ими было удобно оперировать. Помимо этого очень большое значение дает понимание команды, в каких частях общей работы получится выгода. Если понимания нет, то и «заставить» никого не получится
«но всё внезапно становится сложно когда нужно передавать состояние из шага в шаг или хочется прокидывать в тест сложные объекты». Скажу на примере фреймворка Gauge, но у Cucumber тоже есть такие механизмы — передача параметров между степами, они хранятся в рамках сьюта, их можно записывать и получать. Не скажу про «сложные объекты», т.к не указано, что именно нужно нужно передать.
BDD это дополнительный слой абстракции, тут согласен. С другой стороны это возможность написать автотест тестировщику, который пока никак не дружит с кодом.
По поводу костыелей при имплементации: это проблема. Контролы могут быть разные, технологи разные. Но мы как раз и упомянули в статье о проблемах реализации BDD, в некоторой степени нам помогла библиотека Masquerade, в некотрой степени изменение процесса.
Если стабильные степы (шаги) падают, то тут уже полет фантазии, если это связано с особенностью работы с новым функционалом, то возможно придется плодить несколько вариантов практически одного и того же, либо усложнять текущий.
Предположу, что варианты шагов нужно упростить, либо переписать в таком виде, как будет удобно воспринимать большинству. Имплементаций остается, а именование меняется, ну либо создается чуть больше частных случаев.
Про кукумбер скажу — есть знакомые, кто пишет без знания движка под капотом. Есстественно всему нужно некоторое время подучиться, как в случае с примером о «service._»
По поводу сложности: действительно есть сложность в том случае, если аналитик не знает каким глоссарием оперировать. Если система разработки не подсказывает или не подсказывает утилита в которой есть список этих фраз, то шаги будут записаны в произвольной форме, и их нужно будет корректировать, но все же проще подкорректировать одну точку входа, чем синхронизировать тестовую документацию, описание требований и автотест.
Согласен с тем, что не каждый аналитик пишет тесты ) Для аналитика является хорошей практикой описывать юзер кейсы, т.е описывать как (и зачем) поведет себя пользователь и система, т.е. ожидаемый результат. И это является почти тем же самым что и описание сценария. Вопрос в том, ставилась ли задача работать по BDD, если да, то вся команда должна понимать, что мы делаем с требованиями, соответственно когда их записываем, кто отвечает за результат того что записали, а это результат всего взаимодействия заказчика и исполнителя.
Gennadii_M спасибо за первый комментарий )
Суть BDD как раз в том, что бы точка входа была одна, т.е. что бы требования соответствовали тому, как будет тестироваться. В вашем же случае возникат вопрос, документация требований, тестовая документация у вас ведется отдельно? И сами тесты никто не смотрит, кроме службы QA? Описанный Вами пример больше соответствует TDD, хотя упомянули то, что не пишете тест до разработки, получается TLD. Написание тестов на фреймворке jUnit с поведенческой точки зрения это логично, у нас тоже использовалось раньше и используется сейчас, но там нет связи с материалом, который поймет заказчик. Если взять частный случай, на примере нашей компании, то для обхода этой ситуации у нас есть решение. Для того что бы связать jUnit и читаемое любым человеком языком описание есть инструмент QA Lens, который мапит jUnit тесты на документацию.
Скажите, пожалуйста, если не серет, почему нежелательно писать текстовое описание, который поймет не технический специалист? И какой фреймворк использовался?
Интересная статья, спасибо! Читал без акцента на формулировки, как другие комментаторы, но с сутью согласен.
Если я правильно понял вопрос - "что будет, если не использовать фреймворк masquerade, и пользоваться selenium для автоматизации CUBA проектов (или вообще)?", то ответ - суть не изменится, просто на разработку и поддержание тестов нужно будет закладывать больше времени, что имеет свои последствия - бюджет и целесообразность. Можно использовать BDD и на чистом Selenium без всяких селенидов и других библиотек, но без упрощения разработки и поддержки тестов все эти начинания часто теряют смысл.
По поводу костыелей при имплементации: это проблема. Контролы могут быть разные, технологи разные. Но мы как раз и упомянули в статье о проблемах реализации BDD, в некоторой степени нам помогла библиотека Masquerade, в некотрой степени изменение процесса.
Если стабильные степы (шаги) падают, то тут уже полет фантазии, если это связано с особенностью работы с новым функционалом, то возможно придется плодить несколько вариантов практически одного и того же, либо усложнять текущий.
По поводу сложности: действительно есть сложность в том случае, если аналитик не знает каким глоссарием оперировать. Если система разработки не подсказывает или не подсказывает утилита в которой есть список этих фраз, то шаги будут записаны в произвольной форме, и их нужно будет корректировать, но все же проще подкорректировать одну точку входа, чем синхронизировать тестовую документацию, описание требований и автотест.
Суть BDD как раз в том, что бы точка входа была одна, т.е. что бы требования соответствовали тому, как будет тестироваться. В вашем же случае возникат вопрос, документация требований, тестовая документация у вас ведется отдельно? И сами тесты никто не смотрит, кроме службы QA? Описанный Вами пример больше соответствует TDD, хотя упомянули то, что не пишете тест до разработки, получается TLD. Написание тестов на фреймворке jUnit с поведенческой точки зрения это логично, у нас тоже использовалось раньше и используется сейчас, но там нет связи с материалом, который поймет заказчик. Если взять частный случай, на примере нашей компании, то для обхода этой ситуации у нас есть решение. Для того что бы связать jUnit и читаемое любым человеком языком описание есть инструмент QA Lens, который мапит jUnit тесты на документацию.
Скажите, пожалуйста, если не серет, почему нежелательно писать текстовое описание, который поймет не технический специалист? И какой фреймворк использовался?