впроваджуємо phpunit

Якщо ви в черговий раз знаходите себе в ситуації, коли пишете скрипт приблизно такого вигляду:

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

У наше століття Composer і керованих залежностей установка чого завгодно спрощена до межі. За умови, звичайно, що необхідна бібліотека є в Packagist.

Перевіримо коректність установки PHPUnit, запросивши версію:

Інструкції наводяться для версії 6.3.

Зрозуміло, що ви не хочете кожен раз вручну вказувати всілякі аргументи типу --bootstrap при запуску phpunit. а тому найкраще буде відразу ж, до початку роботи, вказати всі необхідні параметри для системного запуску тестів. Налаштував - і забув!

Налаштування PHPUnit зберігаються в XML-файлі в корені вашого проекту. Краще відразу використовувати phpunit.xml.dist. а не phpunit.xml. щоб у ваших колег була можливість створити свої налаштування для тестів або свою добірку тестів.

Що ми робимо

Приклад мінімального файлу phpunit.xml.dist. який має на увазі, що автозавантажувач і все необхідне для роботи наших класів инициализируется в vendor / autoload.php. і що всі тести лежать в каталозі tests в корені проекту, і в підкаталогах цього каталогу.

Якщо потрібна якась ще ініціалізація крім Автозавантажувач, то замість vendor / autoload.php. який генерує Composer, можна і потрібно використовувати app / common.php або подібний.

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

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

Що ми отримали

Приблизно оцінити список класів, які будуть задіяні, можна так:

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

застосування

Найпростіший вид тесту являє собою.

  • Метод класу, що починається на test,
  • в класі, що закінчується на Test,
  • і спадщини від \ PHPUnit \ Framework \ TestCase.

Розумію, складно і заплутано. Але подивимося на приклад такого класу:

Як бачите, нічого особливо складного.

Досить буде визначити цей клас в tests / ExampleTest.php і ми зможемо випробувати PHPUnit:

Ця команда повідомить нам про успішне проходження всіх тестів:

практичний приклад

Щоб не ходити далеко, перепишемо скрипт з початку цієї замітки.

Ось так могло б виглядати визначення для тестованого класу ExampleClass:

Що далі?

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

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

Складно про просте