Зелена галочка не доводить правильність тесту

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

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

Проблема оракула, одним абзацом

Кожен тест має дві половини. Перший тайм щось робить. Другий тайм вирішує, чи правильний результат. Ця друга половина є оракулом, і це половина має значення. Слабкий оракул перевіряє найближчий видимий сигнал: сповіщення, зупинка спінера, зміна URL-адреси. Потужний оракул незалежно перевіряє результат: запис у базі даних, відповідь API, яку викликає сторінка, стан після нового перезавантаження.

У власному посібнику з найкращих практик від Playwright йдеться про дії: тести мають перевіряти поведінку, яку бачить кінцевий користувач, і уникати зв'язку з деталями реалізації, такими як класи CSS. Той самий принцип, застосований до тверджень, дає вам правило для ери ШІ. Стверджувати про результат, який користувач перевірив би через шлях, який помилку не можна підробити.

Чому написані ШІ тести дрейфують у бік слабких оракулів

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

Автоматичне очікування драматурга робить це безпечнішим, ніж є. Перевірки працездатності підтверджують, що елемент видимий, стабільний і отримує події до того, як буде зроблено клацання. Автоматичні повторні перевірка очікують очікуваної умови. Обидва зменшують збої, пов'язані з часом. Жоден не запитує, чи була умова правильною. Тест може бути абсолютно стабільним і абсолютно неправильним.

Три оновлення Oracle, які працюють сьогодні

Перезавантажте та прочитайте. Після збереження перейдіть назад і назад або перезавантажте та підтвердьте, що значення все ще там. Це перевіряє стійкість так, як користувач помітив би її відсутність.

Затвердити один рівень вниз. Режисер може дочекатися відповіді мережі, від якої залежить інтерфейс користувача. Поєднайте перевірка UI із expect(response).toBeOK() у виклику API, який фактично зберігає, або надішліть запит API безпосередньо після потоку UI та порівняйте збережене значення.

Перевірте побічний ефект поза смугою. Щоб зареєструватися, стверджуйте в папці "Вихідні", журналі аудиту або списку адміністраторів, а не на банері привітання. Банер призначений для появи; запис існує тільки в тому випадку, якщо система працювала.

Питання для огляду, яке змінює все

Якщо ви дозволите агентам писати тести, а людям переглядати їх, витрачайте час на перевірку на одне запитання кожного тесту: що це означає та чи може це прийняти, якщо функція не працює? Огляд основного сценарію читання тесту. Перегляд оракула є перевіркою тесту.

Це також чесний спосіб використовувати такий інструмент, як AnyTest. Його агенти досліджують вашу програму за URL-адресою, створюють наскрізні тести та залишають їх для вашого перегляду. Поверхня огляду показує кожен крок і його результат. При правильному використанні цей огляд є місцем, де відбувається перевірка оракула: не "чи агент натискав правильні речі", а "чи тест, який він написав, щось довів". Власний матеріал постачальника говорить, що люди все ще вирішують. Це рішення має значення.

Зелена галочка говорить про виконання тесту. Це ніколи не скаже вам, що тест був правильним.