Як можна писати тести на селен (або подібні), які не виходять із-за незначних чи косметичних змін?

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

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

ви написали тести на селен (або інші подібні), і як ви маєте справу з крихким характером тестів (або як ви перестаєте їх бути крихкими), і для яких типів ви використовуєте селен?

Метою Selenium є створення інтеграційних тестів, керованих інтерфейсом .

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

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

Не намагайтеся отримати все тестове покриття від цього виду тестів . Роберт К. Мартін стверджує, що охоплення вашого коду тестами інтеграції має становити близько 20% . Тестувати всі шляхи виконання, коли вхід знаходиться за декількома шарами програми, просто недоцільно.

Отримайте більшу частину покриття тесту за допомогою тестування одиниць та прийняття . Шукайте посилання на статті Гойка Аджича у відповіді FinnNk . Аджич неодноразово сперечався про тестування бізнес-логіки через тести прийняття та обхід інтерфейсу.

Але деяку кількість тестів, керованих інтерфейсом, потрібно ще написати . Тут вам потрібні практичні поради, крім того, щоб "не перевіряти свою логіку бізнесу через інтерфейс користувача". Я б порекомендував блог Патріка Вілсона-Уельса в якості вихідної точки.

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

Наприклад, скажімо, ви збираєте чиєсь ім’я з двох текстових полів у 100 тестів. Якщо ви будете писати ці тести прискіпливо (або, можливо, використовуєте відтворення запису), вам доведеться змінити 100 тестів. Якщо замість цього ви абстрагуєтесь крок "введіть ім'я" і використовуєте це у своїх тестах замість того, щоб безпосередньо використовувати селен, то у вас є лише 1 місце для внесення змін. Залежно від вашого контексту буде залежати кількість шарів абстракції, які ви використовуєте, але використання абстракції пройде довгий шлях до того, щоб зробити ваші тести сталими.

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

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

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

Особисто я вважаю, що якщо наявність <div>тегу порушує тест, тест непотрібно суворо залежати від оточуючих тегів, і слід використовувати більш м'який підхід.