Ми часто приділяємо багато часу створенню наративу як підходу до написання користувацьких історій відповідно до найкращих практик. Наприклад, «Як… я хочу… щоб…»
Не зрозумійте мене неправильно, наратив користувацької історії є критично важливим для передачі мети та цінності користувацької історії. Ось лише один із багатьох онлайн-ресурсів, що пояснюють переваги наративу користувацької історії та те, як добре написані користувацькі історії допомагають власникам продукту доносити функції до команди. Але чи не є так само важливим, якщо не більш важливим, обговорення критеріїв прийнятності в користувацькій історії?
Добре написані критерії прийнятності скорочують розрив між вимогами та розробкою, який часто губиться в прогалинах комунікації. Одна з найкращих практик написання критеріїв прийнятності, визнаних у галузі, — це формат Behavior-Driven Development (BDD). У міру того як BDD набував популярності серед практиків гнучкої розробки, почали з’являтися деякі поширені хибні уявлення.
Мета написання у форматі BDD
Існує багато ресурсів, що пояснюють хибні уявлення про BDD та його зв’язок з Gherkin і автоматизованими тестами на основі Cucumber. По суті, ми використовуємо формат BDD для того, щоб синтаксис, який описує вимоги, був максимально наближений до синтаксису, який інженер використовував би для написання та виконання тестів.
Як і Agile-маніфест і принципи, в яких ці настанови пояснюють, чому ми діємо і мислимо саме так, BDD часто неправильно інтерпретують. Наприклад, скільки разів ми чули твердження: «ми не займаємося документацією, бо працюємо за agile!»
Оскільки це не чергова стаття про те, як застосовувати BDD, я припускаю, що ми однаково розуміємо базові принципи.
Тобто:
«Given» — це передумови, стан, параметри, що стосуються конкретного сценарію. Встановлення контексту.
«Коли» — це тригер, або зміна стану, те, що ми тестуємо
«Then» — це очікуваний результат (або результати) тригера з урахуванням контексту передумов
Поширені помилки та антипатерни в BDD
«Помилки» — це спірне слово в даному випадку, і ось чому. Оскільки ми використовуємо BDD через його схожість із природною мовою, часто вважається, що якщо твердження BDD є граматично правильним, тобто легко вимовляється носієм англійської мови, воно має бути коректним.
І оскільки ми цінуємо «працююче програмне забезпечення понад вичерпну документацію», це не повинно мати великого значення, якщо команда правильно це розуміє, чи не так? Спірне питання.
Тож підготуйтеся, візьміть антистресовий м’яч, приберіть подалі гострі предмети і давайте зануримося та розглянемо деякі поширені антипатерни BDD.
Не питання «чи станеться», а питання «коли»
Ось одна помилка, яка зустрічається найчастіше: хоча це, безсумнівно, легко вимовляється і може бути легко зрозумілим, воно явно порушує основний принцип формату «Дано-Коли-Тоді».
Кращим способом написати це може бути:
Враховуючи, що введене значення в текстовому полі «Число» не є числовим
Коли форма надсилається
Тоді з’являється повідомлення про помилку «Будь ласка, введіть числове значення».
На цьому етапі ви, мабуть, думаєте: «Велика справа! Ви кажете то-мей-то, я кажу то-ма-то! Чи не так?» Насправді ні. Уявіть собі написання подібного сценарію, який перевіряє текстове поле лише в тому випадку, якщо користувач увійшов у систему.
Якщо ми дотримуємося неправильного прикладу:
Враховуючи, що введене значення в текстовому полі «Число» не є числовим
Коли форма надсилається
Тоді з’являється повідомлення про помилку «Будь ласка, введіть числове значення»
Враховуючи, що користувач увійшов у систему ← Умова
І значення в текстовому полі «Число» змінюється ← Тригер
Коли значення в ньому не є числовим ← Умова? Тригер?
Тоді з’являється повідомлення про помилку «Будь ласка, введіть числове значення»
Це ще більше розмиває межу між передумовою та тригером, що фактично нівелює мету чітко визначеного формату BDD.
Щоб пояснити цю думку детальніше: якщо нас не цікавить, що куди відноситься, аби лише текст був зрозумілим, то чому б просто не відмовитися від секції «Given» повністю?
Щоб дійсно відповідати формату BDD, кращим способом написання цього могло б бути:
Коли Коли Коли
Слідуючи антипатерну змішування передумови (Given) та тригера (When), ми іноді бачимо, як люди пишуть кілька операторів ‘When’, використовуючи оператор ‘And’.
Ось приклад, де це неправильно:
З огляду на те, що я знаходжусь на формі реєстрації
Коли я вводжу свої дані
Отже, яку саме поведінку ми тут тестуємо?
Це поведінка введення імені? Введення електронної пошти? Введення пароля? Чи це тестує поведінку надсилання даних реєстрації?
А що щодо валідності цих полів, які були введені? Звісно, на ці питання можна легко отримати відповідь у простій розмові з командою. Зрештою, картки історій слугують покажчиком для розмов.
Однак уявіть такі розмови у масштабі — для кожного критерію приймання кожної історії. В ідеалі критерії приймання мають бути сформульовані якомога однозначніше, щоб ми могли приберегти час для обговорення складніших питань. Є справи важливіші.
Речення When повинно містити лише один тригер, а речення Given повинно перераховувати всі умови, які впливають на цей тригер.
Наприклад:
З огляду на те, що я знаходжусь на формі реєстрації
І всі ці обов’язкові поля заповнені
Чітка відмінність між цими двома прикладами полягає в тому, що правильний приклад має чіткий тригер, тобто відправлення форми; з чіткою передумовою, тобто поля пройшли валідацію; неправильний приклад має послідовність подій у тригері.
Передумова проти послідовності подій
Хоча ми прагнемо до однозначності під час написання користувацьких історій, ми можемо перестаратися і потрапити в пастку надмірних пояснень.
Візьмемо приклад сценарію для повторного підтвердження вибору місця в літаку:
За умови, що я обрав рейс на сторінці вибору рейсу
І я вирішив пропустити вибір місця на сторінці вибору місця
І я обрав харчування на сторінці вибору харчування
Коли я підтверджую свої дані на сторінці підтвердження деталей
Тоді має з’явитися попереджувальне повідомлення “Місце буде призначено випадково, продовжити”.
Знову ж таки, на перший погляд це виглядає правильно, і, чесно кажучи, написати приймальні тести для цього нескладно. Проте існує простіший і кращий спосіб написання того самого сценарію:
У цьому прикладі розділ передумов спочатку встановлює контекст, а потім згадує єдину передумову, яка має значення в цьому сценарії.
Це спрощення зроблено тому, що в даному випадку ці речі не мають значення:
Потік та порядок, у якому користувач потрапляє на сторінку підтвердження деталей
Дії та параметри (окрім пропуску вибору місця), які користувач виконав до цього
Роблячи конкретний сценарій або тест таким, що охоплює якомога менше етапів, ми робимо його менш вразливим до майбутніх змін і часто потребуємо меншої кількості тестів для охоплення всіх сценаріїв.
Що стосується модульних тестів — ми тестуємо найменшу окрему одиницю функціональності.
Заключні думки
Хоча я не вважаю себе експертом з BDD і не прагну читати лекції колегам-практикам на цю тему, я, проте, є переконаним прихильником думки, що «технічно правильно — це найкращий вид правильності».
Коли Ден Норт започаткував BDD, існували причини, чому Given-When-Then були обмежені визначенням Передумова-Тригер-Результат. Деякі з цих причин поширюються на принципи тестування, такі як Arrange-Act-Assert та чотирифазні тести.
Зрештою, добре написані критерії прийняття слугують двом цілям. По-перше, чітко донести до нетехнічної аудиторії, що ці критерії будуть використовуватися для перевірки поведінки функції. По-друге, і не менш важливо, забезпечити можливість легкого перетворення цієї вимоги на код для розробки та тестування. BDD є вдалим засобом для досягнення цих результатів.
З огляду на ці причини, я вважаю, що хоча читабельність BDD-тверджень є важливою, є сенс відстоювати правильний спосіб написання BDD-тверджень, які чітко дотримуються формату «Given (Передумови) — When (Тригер) — Then (Результати)»
Оригінальна стаття — Applying BDD acceptance criteria in user stories від Dennis Hee, переклад та ревью — Іван Вільчавський. Зображення з оригінальної статті.