Використовуйте тести як докази

Почніть із вимоги

Тести — це докази конкретних тверджень. Успішний запуск тестів не підтверджує всіх властивостей програмного забезпечення. Перед запитом на тести визначте важливу поведінку та дефект, який має виявляти кожна перевірка.

Для вигаданого експорту даних організації головна вимога — ізоляція даних. Користувач організації A не повинен отримувати записи організації B. Тест, що перевіряє лише успішне завантаження, не підтверджує цієї вимоги.

Попросіть агента пояснити зв’язок між вимогою та твердженням, яке перевіряє тест. Це полегшує виявлення пропущених випадків до того, як набір тестів стане великим.

Оберіть відповідний обсяг тесту

Модульний тест може швидко перевірити невелике перетворення. Інтеграційний тест може перевірити спільну роботу компонентів. Наскрізний тест може перевірити важливу послідовність дій користувача в розгорнутому застосунку або його репрезентативному середовищі.

Використовуйте найвужчий обсяг, який дає потрібні докази. Інструменту форматування не потрібен повний браузерний тест для кожного вводу. Межа авторизації може потребувати справжнього маршруту та шляху доступу до даних. Критична взаємодія в браузері потребує доказів щодо відображеного інтерфейсу.

Жодне фіксоване співвідношення типів тестів не підходить усім системам. Обирайте з огляду на збій, який потрібно виявити, та вартість підтримки перевірки.

Уникайте спільного хибного припущення

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

Припустімо, реалізація фільтрує записи за ідентифікатором організації із запиту. Тест використовує однаковий ідентифікатор для автентифікованого користувача й запиту. Він проходить. Пропущений випадок — користувач, який запитує ідентифікатор іншої організації.

Додайте цей випадок через фактичний шлях довіреної ідентичності та авторизації. Підміна, що завжди повертає «дозволено», не може підтвердити ізоляцію орендарів. Вона підтверджує лише поведінку після успішної авторизації.

Перевірте, що тест може не пройти

Для відомого дефекту запустіть новий регресійний тест на дефектній версії в ізольованій гілці. Підтвердьте, що він не проходить саме з очікуваної причини. Потім застосуйте виправлення та запустіть його повторно.

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

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

Зберігайте зв’язок доказів зі зміною

Запускайте відповідні перевірки на остаточній ревізії. Записуйте пропущені перевірки та причини. Результат попереднього commit може вже не стосуватися коду після виправлення за результатами перегляду.

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

Рецензент має вміти пояснити, що тести підтверджують, а що залишається невизначеним. Таке пояснення корисніше за велику кількість тестів.