Кращі практики для тестування регресії веб-сайтів WordPress?

Привіт усім,

Мені хотілося б почути, що інші, хто постачає комплексні неблокові рішення клієнтам з WordPress як платформою, що вони використовують для автоматизованого тестування регресії ?

Для тих, хто не знайомий з терміном "регресійне тестування", Вікіпедія визначає його як:

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

Більше розповідаючи у Вікіпедії, йдеться про наступне, що саме зараз я відчуваю над проектом:

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

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

Моїм рішенням було б встановити регресійне тестування із серією "тестових випадків", щоб містити "набір тестів". Насправді це не так складно, коли ви протестуєте вихід HTML-запитів HTTP GET-запитів. Але це стає трохи складніше, коли вам доведеться перевірити речі під час входу через консоль адміністратора та / або перевірити взаємодію jQuery.

Я налаштовую це як вікі спільноти, сподіваючись, що ми можемо зібрати тут найкращі практики, але мені дуже хочеться почути процеси, якщо користуються інші фахівці WordPress.

PHPUnit прийде в голову, якби пакет тестів WP був не таким зламаним, і якщо WP був розроблений і написаний таким чином, що він насправді міг би бути перевірений належним чином. ;-)

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

Серед барвистих речей, які я бачив:

• Тонка зміна API WP впливає на функціональність вашого плагіна, наприклад, на гачок, який ви використовуєте для отримання ідентифікатора терміна, і тепер він отримує ідентифікатор терміна таксономії. (Цілком імовірно, що ваші умови тестування зручно мати однаковий ідентифікатор для обох).

• Тонка зміна API WP призводить до отримання WP_Errorоб’єкта замість очікуваного раніше значення falseяк неправильного вводу.

• Ваш плагін додається з папки mu-plugins, що призводить до тонко іншого потоку коду.

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

• Ваш плагін справно працював, поки не подзвонили зневажений switch_to_blog ().

• Плагін змінює гачок, на якому він знаходиться, коли викликається, і несвідомо перериває його як побічний ефект.

• Плагін (не?) Свідомо заплутується з вашими вхідними або вихідними даними до тієї точки, коли все виглядає зламаним, навіть якщо ви не винні.

Я міг би розширити список і далі, але це були б основні елементи, які зламали мої власні плагіни. Два елементи, можливо, підлягають ловуванню за допомогою одиничних тестів. Наступні два, якщо ви достатньо терплячі, але я стверджую, що WP не повинен змінювати спосіб роботи, коли вони відбуваються. Жодна кількість тестування не працюватиме навколо помилкової реалізації switch_to_blog (). І останні два безнадійно незаперечні.

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

Удачі... :-)

Вам слід рішуче врахувати Селен .

Це дозволяє записувати дії (наприклад, введення даних у форму, натискання посилання), а потім ви можете виконувати твердження. Він також інтегрується з PHPUnit. Я настійно рекомендую ознайомитись з демонстрацією на дві хвилини.

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

Звичайно, тести Codeception WebDriver можуть піти далі та виконувати тести функціональної регресії. Ви можете заповнювати та надсилати форми, натискати кнопки та посилання на сайті, виконувати будь-який JS тощо. Ви можете використовувати браузер у реальному житті, як Firefox чи Chrome, у своїх тестах, а також можна провести тестування без голові за допомогою PhantomJS . Це означає, що ви навіть можете запустити тести WebDriver для свого плагіна як частина його процесу збирання на Travis CI, якщо ви цього хочете.

Існує навіть декілька специфічних для WordPress бібліотек, які допоможуть вам почати:

• WP-браузер
• WP кодецепція