Що таке тести і TDD простими словами

Що таке тест простими словами

Зібрав шафу з IKEA. Дверцята відчиняються, полиці стоять - краса, хоч у сторіс викладай. За тиждень прикручуєш нову полицю і ненароком перекошуєш дверцята. А ти цього не бачиш. Побачиш за місяць - коли дверцята урочисто відваляться тобі на ногу.

Щоб такого не було, придумали тести. Тест Тест - маленька програма-перевіряльник. Вона сама запускає твій код, подає йому дані і перевіряє, що результат правильний. Якщо щось не так - голосно кричить «зламалося». - це робот, який після кожної твоєї правки обходить усю шафу і смикає кожні дверцята: відчиняються? зачиняються? не перекошені? Смикнув - і одразу доповів. «Усе ок» або «ось тут відвалилося, лагодь».

А TDD - це просто звичка. Спочатку покликати робота-перевіряльника, і тільки потім будувати.

Навіщо тести потрібні вайбкодеру

Ти вайбкодер. Тести руками ти не пишеш - їх напише агент. Але якщо розумієш, навіщо вони взагалі, то отримуєш одразу чотири приємні бонуси:

• перестаєш боятися чіпати код - робот сам скаже, якщо щось поїхало;
• ловиш баги до того, як їх помітить користувач (а тим паче замовник);
• спокійно просиш агента «перепиши гарніше» - тести підстрахують;
• і нарешті розумієш, навіщо агент «спершу пише перевірку, яка падає». Це не глюк. Це метод.

Різниця між «мій сайт постійно десь ламається, і я не розумію де» та «міняю що хочу і сплю спокійно» зазвичай зводиться до одного слова: тести.

Цикл TDD: червоний, зелений, причесати

Просиш агента працювати за TDD - і він не кидається писати код наосліп. Він іде за чітким циклом. Ось він, без мудрованих слів.

Крок 1. Описуємо, чого хочемо

Спочатку агент формулює задачу очима користувача: «Я як покупець хочу шукати товари за змістом, щоб знаходити потрібне навіть без точних слів». Це називається user journey User journey - коротка історія «хто хоче що і навіщо». Допомагає зрозуміти, що взагалі треба перевіряти, ще до написання коду. . З неї одразу ясно, що перевіряти.

Крок 2. Пишемо тест - і він СПЕЦІАЛЬНО падає

Далі починається дивне. Агент пише перевірку до коду. Зрозуміло, що вона тут-таки падає - коду ж іще немає! Це і є червоний RED (червоний) - стан, коли тест написаний, запущений і впав. Це нормально і обовʼязково: так ми переконуємося, що тест взагалі працює і реально перевіряє потрібне. етап.

Крок 3. Пишемо мінімум коду, щоб тест позеленів

Тепер агент пише рівно стільки коду, щоб тест пройшов. Ні рядком більше. Тест із червоного стає зеленим GREEN (зелений) - тест запущений після написання коду і пройшов. Значить, потрібна поведінка справді працює. . Робот задоволений. Ти теж.

Крок 4. Наводимо красу (рефакторинг)

Код працює, але виглядає, скажімо мʼяко, абияк. Ось тепер його можна причісувати - прибрати дублі, перейменувати зрозуміліше. І після кожного кроку ганяти тести: поки вони зелені - ти нічого не зламав.

Види тестів: юніт, інтеграція, E2E

Тести бувають трьох «розмірів» - від дрібного до великого. Хороший агент покриває всі три, а не один улюблений.

Хороший тест проти поганого: як відрізнити

Найчастіша пастка: тест начебто є, а перевіряє не те. Ось як відрізнити надійного робота від декоративного. Це прямо з правил скіла tdd-workflow.

Приклад із життя: як промокод ламає кошик

Зробив інтернет-магазин. Кошик рахує суму - працює. За тиждень просиш агента: «додай знижковий промокод». Він додає. Промокод працює! Ти радієш і йдеш спати як немовля.

А вранці сюрприз: після додавання промокоду звичайна сума без знижки почала рахуватися з копійчаною помилкою. Ти цього не помітив, бо перевіряв тільки промокод. Зате помітив клієнт - і лишив теплий відгук на одну зірку.

З тестами цього б не було. Робот-перевіряльник після правки промокоду сам перерахував би і звичайний кошик, і заволав би: «гей, тут тепер 99 гривень замість 100, лагодь». За три секунди - до сну, а не після.

Ось як попросити агента працювати так, щоб він тебе страхував:

Додай у кошик підтримку знижкових промокодів. Працюй суворо за TDD:

Спочатку опиши простими словами, що має відбуватися: що вводить користувач і що він має побачити.
Напиши тести ДО коду. Обовʼязково перевір і звичайний кошик без промокоду - я хочу бути впевнений, що його не зламали.
Запусти тести і покажи мені, що новий тест падає. Це нормально, так і має бути.
Тепер напиши мінімум коду, щоб усі тести стали зеленими.
Запусти тести знову і покажи, що все зелене.
Перевір крайні випадки: порожній промокод, неіснуючий промокод, знижка більша за суму.

Як спіймати тести, написані «для галочки»

Буває, агент квапиться і вдає, що протестував. Пробіжись по чек-листу - це прямо суть скіла tdd-workflow.

1. Тест реально падав? Агент одразу показав зелене, не показавши червоне? Можливо, тест не перевіряє анічогісінько.
2. Старе прогнали? Нова фіча не повинна ламати те, що працювало. Спитай прямо: «а старе ти перевіряв?».
3. Чи є погані сценарії? Порожнє введення, помилка, дивні числа - не тільки «коли все добре».
4. Тест чіпляється за зміст, а не за стиль? «Кнопка Купити», а не безіменний css-клас.
5. Тести незалежні? Кожен сам готує дані і не сподівається на сусіда.

Часті помилки новачків у TDD

• Просити код без тестів. «Просто зроби» - а потім дивуватися поломкам. Додавай «працюй за TDD».
• Вірити зеленому, не бачивши червоного. Тест жодного разу не падав? Значить, може, і не перевіряє нічого.
• Тестувати тільки нову фічу. Головна користь тестів - спіймати, що нове зламало старе.
• Перевіряти тільки «коли все добре». Реальні дані бувають порожні, криві і злі.
• Чіплятися за крихке. Тест по css-класу падає від будь-якої зміни дизайну. Чіпляйся за зміст.
• Зносити тести, коли вони заважають. Тест, що падає, - не ворог. Це робот, який щойно врятував тобі ногу.