Comments 26
Давайте начнём дискуссию ) Я живу несколько в другом мире в контексте бдд. В нём не обязательно писать тесты на геркине, их можно писать и кодом. А суть в том, чтобы мыслить поведением, а не реализаций. На примере UI автоматизации логина реализацией будет
Проблема здесь в том, что, если процедура логина поменяется, то править нужно будет большое количество тестов. С этим нам и помагает бдд:
Реализацией метода логин как раз и будет весь предыдущий код. Теперь изменения будут только в одном месте. Геркин тут не обязателен (а в моём мире ещё и нежелателен) ровно как и писать такие тесты до реализации кода, за что отвечает TDD подход. Миксовать их необязательно (но в моём мире желательно), т.к. они в принципе решают разные независимые друг от друга проблемы.
PS Я не утверждаю, что автоар не прав, но буду рад подискутировать, ибо в споре рождается истина.
loginPage.loginField.enterText('login');
loginPage.passwordField.enterText('password');
loginPage.loginButton.click();Проблема здесь в том, что, если процедура логина поменяется, то править нужно будет большое количество тестов. С этим нам и помагает бдд:
loginService.login('login', 'password');Реализацией метода логин как раз и будет весь предыдущий код. Теперь изменения будут только в одном месте. Геркин тут не обязателен (а в моём мире ещё и нежелателен) ровно как и писать такие тесты до реализации кода, за что отвечает TDD подход. Миксовать их необязательно (но в моём мире желательно), т.к. они в принципе решают разные независимые друг от друга проблемы.
PS Я не утверждаю, что автоар не прав, но буду рад подискутировать, ибо в споре рождается истина.
Получается вы рассматриваете BDD как упрощение написания кода, когда речь идет о том, чтобы писать тесты на понятном человеку, без опыта программирования, языке. Не каждый Бизнес Аналитик, сможет читать код и уж тем более писать на нем.
Не каждый бизнес аналитик пишет тесты ) Это раз, два — у меня был проект на кукумбере. Я туда пришёл на синьёрную позицию и первые 3 месяца не мог самостоятельно писать тесты как раз из-за кукумбера (конечно, там было не самое лучшее решение и можно сделать лучше, но проблемы всё равно есть в плане написания не программистами). И три — я делал эксперимент: посадили мануальщика, сказали, что есть какое-то слово service и, если после него нажать точку, то будут подскази чего тут можно делать дальше. И парень сам написал тест без подсказок вообще. Так что вопрос спорный )
Ну суть как раз в том, чтобы аналитик начал их писать :)
И я не спорю, что научить можно кого угодно и чему угодно, весь вопрос в сроках и целесообразности.
И я не спорю, что научить можно кого угодно и чему угодно, весь вопрос в сроках и целесообразности.
Вы знаете аналитика без знаний программирования, который может сам писать тесты на кукумбере? А моём опыте это было чрезмерно сложно, как в написании, так и в поддержке.
С использованием Gauge, да.
Про кукумбер скажу — есть знакомые, кто пишет без знания движка под капотом. Есстественно всему нужно некоторое время подучиться, как в случае с примером о «service._»
По поводу сложности: действительно есть сложность в том случае, если аналитик не знает каким глоссарием оперировать. Если система разработки не подсказывает или не подсказывает утилита в которой есть список этих фраз, то шаги будут записаны в произвольной форме, и их нужно будет корректировать, но все же проще подкорректировать одну точку входа, чем синхронизировать тестовую документацию, описание требований и автотест.
По поводу сложности: действительно есть сложность в том случае, если аналитик не знает каким глоссарием оперировать. Если система разработки не подсказывает или не подсказывает утилита в которой есть список этих фраз, то шаги будут записаны в произвольной форме, и их нужно будет корректировать, но все же проще подкорректировать одну точку входа, чем синхронизировать тестовую документацию, описание требований и автотест.
Согласен с тем, что не каждый аналитик пишет тесты ) Для аналитика является хорошей практикой описывать юзер кейсы, т.е описывать как (и зачем) поведет себя пользователь и система, т.е. ожидаемый результат. И это является почти тем же самым что и описание сценария. Вопрос в том, ставилась ли задача работать по BDD, если да, то вся команда должна понимать, что мы делаем с требованиями, соответственно когда их записываем, кто отвечает за результат того что записали, а это результат всего взаимодействия заказчика и исполнителя.
Задача ставилась, но решение с кукумбером было на столько сложным к написанию, что задачи писать тесты не автоматизаторам не было. Написано было на английском не как код, да, но писать самому аналитику — вообще никак )
Gennadii_M спасибо за первый комментарий )
Суть BDD как раз в том, что бы точка входа была одна, т.е. что бы требования соответствовали тому, как будет тестироваться. В вашем же случае возникат вопрос, документация требований, тестовая документация у вас ведется отдельно? И сами тесты никто не смотрит, кроме службы QA? Описанный Вами пример больше соответствует TDD, хотя упомянули то, что не пишете тест до разработки, получается TLD. Написание тестов на фреймворке jUnit с поведенческой точки зрения это логично, у нас тоже использовалось раньше и используется сейчас, но там нет связи с материалом, который поймет заказчик. Если взять частный случай, на примере нашей компании, то для обхода этой ситуации у нас есть решение. Для того что бы связать jUnit и читаемое любым человеком языком описание есть инструмент QA Lens, который мапит jUnit тесты на документацию.
Скажите, пожалуйста, если не серет, почему нежелательно писать текстовое описание, который поймет не технический специалист? И какой фреймворк использовался?
Суть BDD как раз в том, что бы точка входа была одна, т.е. что бы требования соответствовали тому, как будет тестироваться. В вашем же случае возникат вопрос, документация требований, тестовая документация у вас ведется отдельно? И сами тесты никто не смотрит, кроме службы QA? Описанный Вами пример больше соответствует TDD, хотя упомянули то, что не пишете тест до разработки, получается TLD. Написание тестов на фреймворке jUnit с поведенческой точки зрения это логично, у нас тоже использовалось раньше и используется сейчас, но там нет связи с материалом, который поймет заказчик. Если взять частный случай, на примере нашей компании, то для обхода этой ситуации у нас есть решение. Для того что бы связать jUnit и читаемое любым человеком языком описание есть инструмент QA Lens, который мапит jUnit тесты на документацию.
Скажите, пожалуйста, если не серет, почему нежелательно писать текстовое описание, который поймет не технический специалист? И какой фреймворк использовался?
Я пишу на тайпскрипте, тест раннер — jasmine. Мануальщики код тестов читают без проблем. Заказчик не читает тесты вообще. Ни в коде и в tms.
Единая точка входа — это, конечно хорошо, но только тогда когда тест кейсы написанные мануальщиком автоматически становятся авто тестами. Если их всё равно надо переписывать в авто тесты, то смысл пропадает. А именно так и происходит в 100% случаев, про которые я слышал и видел сам.
А сам кукмбер — это лишний слой абстракции, который накладывает значительные ограничания на архитектуру, которые надо как-то извращённо-костыльно решать.
Единая точка входа — это, конечно хорошо, но только тогда когда тест кейсы написанные мануальщиком автоматически становятся авто тестами. Если их всё равно надо переписывать в авто тесты, то смысл пропадает. А именно так и происходит в 100% случаев, про которые я слышал и видел сам.
А сам кукмбер — это лишний слой абстракции, который накладывает значительные ограничания на архитектуру, которые надо как-то извращённо-костыльно решать.
BDD это дополнительный слой абстракции, тут согласен. С другой стороны это возможность написать автотест тестировщику, который пока никак не дружит с кодом.
По поводу костыелей при имплементации: это проблема. Контролы могут быть разные, технологи разные. Но мы как раз и упомянули в статье о проблемах реализации BDD, в некоторой степени нам помогла библиотека Masquerade, в некотрой степени изменение процесса.
Если стабильные степы (шаги) падают, то тут уже полет фантазии, если это связано с особенностью работы с новым функционалом, то возможно придется плодить несколько вариантов практически одного и того же, либо усложнять текущий.
По поводу костыелей при имплементации: это проблема. Контролы могут быть разные, технологи разные. Но мы как раз и упомянули в статье о проблемах реализации BDD, в некоторой степени нам помогла библиотека Masquerade, в некотрой степени изменение процесса.
Если стабильные степы (шаги) падают, то тут уже полет фантазии, если это связано с особенностью работы с новым функционалом, то возможно придется плодить несколько вариантов практически одного и того же, либо усложнять текущий.
имхо, это для команд, где нет програмистов, а только кодеры
выглядит так, как будьто программист на человеческом языке получил шаги, что надо сделать, и только перевел это в код
причем большая часть работы сделана уже до него
выглядит так, как будьто программист на человеческом языке получил шаги, что надо сделать, и только перевел это в код
причем большая часть работы сделана уже до него
Ильдар, спасибо за статью. Подскажите, как Вам удалось привлечь аналитиков к написанию сценариев в BDD?
Изначально инициатива использования BDD шла от зарубежного заказчика, поэтому было немного проще. Сейчас мы пробуем использование на другом проекте, но тут уже есть интерес у наших аналитиков. Сложность заключается в том «как писать?», поэтому первая задача в данном случае правильно назвать шаги, что бы ими было удобно оперировать. Помимо этого очень большое значение дает понимание команды, в каких частях общей работы получится выгода. Если понимания нет, то и «заставить» никого не получится
Мы сделали BDD на jBehave, так как Java команда могла помочь с быстрым стартом и написанием всех необходимых компонентов для используемых сценариев. Инициатива шла от нашей команды, т.к. при использовании BDD мы сильно экономили на тестировании при частых выпусках новых версий. Я бы не сказал, что BDD это дорого, нужно правильно разложить процесс и посчитать издежки и экономию. Новые компоненты нужны нечасто. В основном тестировщики справляются со сценариями без помощи разработчиков.
Ильдар, я не разбираюсь во фреймворке CUBA. Что изменится в ваших тезисах, если не использовать его, обходясь стандартными подходами и фреймворками?
Если я правильно понял вопрос - "что будет, если не использовать фреймворк masquerade, и пользоваться selenium для автоматизации CUBA проектов (или вообще)?", то ответ - суть не изменится, просто на разработку и поддержание тестов нужно будет закладывать больше времени, что имеет свои последствия - бюджет и целесообразность. Можно использовать BDD и на чистом Selenium без всяких селенидов и других библиотек, но без упрощения разработки и поддержки тестов все эти начинания часто теряют смысл.
Это называется "Открытие Америки" или "Изобретение велосипеда"
Статье больше двух лет. И - да - каждый из нас открывает для себя новые технологии и методики.
К примеру, на GitHub тысячи TIL-репозиториев (Today I Learned).
Поделитесь опытом - что открылось за пару лет? Или покажите TIL, которые не кажутся велосипедом.
Sign up to leave a comment.
Опыт использования BDD