Введення в мистецтво модульного тестування в PHP

Мітки: веб-розробка, модульне тестування

Введение в искусство модульного тестирования в PHP Введение в искусство модульного тестирования в PHP
An Introduction to the Art of Unit Testing in PHP An Introduction to the Art of Unit Testing in PHP

← Як Google насправді хоче щоб ви оптимізували свій сайтІнтеграція FCKeditor в Zend_Form →
Введення
Тестування є суттєвим аспектом в будь-якій мові програмування. Якщо ви не тестуєте свій вихідний код, то як ви можете бути впевнені, що він працює так, як ви очікуєте?
Тестування вихідного коду вручну може проводитися тільки нерегулярно і
обмежено. Для регулярного і поглибленого тестування вихідного коду, відповіддю буде написання автоматизованих тестів, які можна запускати часто. У PHP такі тести зазвичай написані з використанням фреймворку модульного тестування, фреймворк, який дає можливість протестувати вихідний код будь-яких програм або бібліотек, як окремо ізольовані функціональні модулі, як клас або метод. Коли модульне тестування набрало популярності, воно стало звичайною практикою в PHP з бібліотеками і фрейморкамі як Swiftmailer, Zend Framework і Symfony, всі вони включають модульні тести покриваючі їх вихідний код.
Модульне тестування часто розуміється як щось приховане, завдання поглинаюче час - що іноді трапляється! Але мета проведення часу за написанням тестів полягає в тому, щоб поліпшити якість вихідного коду, значить він має менше абсолютних помилок, багато з яких виявляються на ранніх стадіях, безперервний процес тестування запобігає зміні поведінки старого коду при нових змінах, а також дає впевненість, що ваш код може бути залежним. Є також й інші переваги, далі ми обговоримо їх докладніше.

Омани про тестування
Модульне тестування, як і інші форми тестування, впираються в чотири прості пояснення, які ускладнюють розуміння розробників.
1. Це поглинання часу і триває занадто довго.
2. Цілосний код не може бути протестований.
3. Я не маю необхідності в написанні тестів, так як це все довго працює.
4. Тестування нудне.
Це омани про тестування, причини, які звучать переконливо, але насправді вони невірні в тонкощах. Ну що ж, давайте розвіємо деякі з них!
Тестування тільки забирає час. Питання в тому, чому б не використати цей час більш доцільно і відповіддю буде, що це знижує витрачений час у майбутньому, що знадобиться для модифікації, підтримки, рефакторінгу та усунення не знайдених помилок в коді. І ми всі чудово розуміємо, що будуть тонни всяких не виявлених помилок, якщо не проводити тестування ретельно!
Раннє тестування це як ловля горезвісного хробака, так само, як ви пишете код, ви можете використовувати модульні тести для тестування ізольованих методів / класів або груп функціональних класів, безпосередньо. Роблячи так, ви знаходите і виправляєте помилки настільки ж швидко, як тільки вони встигають з'являтися. Проблема в тому, що ви знаходите помилки настільки часто і виправляєте їх настільки швидко, що ви навряд чи помічаєте той час, які вони забирають.
Коли пізніше ви робите зміни і тести провалюються, ви можете виправити внутрішню проблему якомога швидше - більше збереженого часу ледве помітно. Сумарна вигода може бути не помітна і ви можете не помітити її зовсім - і тільки бачити, що тестуючий код забирає кілька годин на його написання, а не помилки, які були виправлені вами за 10 секунд, що могли виправлятися б декілька хвилин, годин, 6 місяців і т.д.
По-друге, це заплутаний код - і цей заплутаний код робиться з менших практичних частин. В ООП проста задача часто піддається тестуванню. Це як лакмусовий тест для якості розподіленого коду. Якщо ваш код не може бути легко протестований, то це не помилка модульного тестування, це проблема з написанням практичного коду, який був би гнучким і розподіленим. Якщо ви тестували як ви написали код, ви б робили наголос на розподіл класів майже на автоматі. Фактичний код представляється занадто заплутаним для тестування, це звичайний симптом для занадто довгого періоду часу перед початком тестування!
По-третє, робочий код і робочий відтестовані код - це два різних звіра. Тести пропонують безпечну систему, для внесення змін, рефакторінгу, а також внесення нових можливостей приносить менше головного болю при додаванні, у той час як питання інтеграції будуть виявлені майже миттєво. Вони також підвищують ефективність від нових програмістів у вашій команді, які не знайомі з кодом, можно бачити їх помилки, які виявляються миттєво за короткий період часу і, отже, набувається досвід у запуску.
В обох випадках, якщо новий код змінює поведінку вже існуючого коду, тести будуть видавати повідомлення. Без тестів, деяка поведінка могла б бути трохи змінена без попередження кого-небудь (в кінці кінців, якщо ви не тестуєте, то як ви можете це виявити, доки кінцевий користувач не вирахує це й не поскаржиться!). Не варто себе підбадьорювати тим, що дещо працює без тестів - почекайте в черзі на вашому публічному баг-трекері та очікуйте очевидного натиску. Якщо вам пощастить, код буде досить простий і, в кінцевому результаті, звіт про помилки виявить більшість проблем і ви зможете усунути їх перед тим, як хто-небудь буде дуже роздратований. Це до сих пір мало для вашої репутації, також як і майбутній ефект від ще більшої кількості не відтестованих змін.
Наостанок, тестування це не завжди нудно. О, я знаю, що часом це може бути нудно, але зазвичай нудно саме тому, що тести пишуться в кінці процесу розробки. Якщо ви часто перемикаєтесь від тестів до коду і назад, ви більше робите і менше позіхаєте. Отже, лікування від нудьги це проста задача перемикання і періодичне тестування написаного - не треба потрапляти в пастку коли потрібно проводити цілі дні за написанням тестів і тільки тестів.
Отже, більше ніяких відмовок. Присядьте, розслабтеся, читайте далі.

Модульне Тестування в PHP
Модульне тестування в PHP може бути представлене трьома способами. Два звичайних варіанти це SimpleTest Маркуса Бейкера і PHPUnit Себастьяна Бергманна. Щоб внести трохи замішання, також є старий надійний: phpt.
Усі три методи дозволяють вам робити модульне тестування коду, а також два фрейморка, що пропонують безліч розширень. Ми візьмемо приклад з використанням PHPUnit. Для установки PHPUnit, можете ознайомитися з відповідним розділом документації (PHPUnit Pocket Guide). Також вам необхідно буде встановити PEAR.
PHPUnit (подібно SimpleTest) організовує тести в випадки; простіше кажучи, клас публічні методи якого є єдиними незалежними тестами. Тут ми збираємося створити клас для представлення флоту (проста модель).
Здається занадто просто, але давайте все-таки рухатися не поспішаючи. Це випадок тесту, який я написав для підняття цього класу на деякий мінімальний рівень, перед тим як ми приймемось за введення в базу даних.
Прибрати підсвітку коду
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

<?php
require_once 'PHPUnit/Framework.php';
require_once 'My/Fleet.php';
 
class MyFleetTest extends PHPUnit_Framework_TestCase
{
    protected $_fleet = null;
 
    public function setUp()
    {
        $this->_fleet = new My_Fleet;
    }
 
    public function tearDown()
    {
        unset($this->_fleet);
    }
 
    public function testShouldNotHaveAnyShipsYetInIntitialState()
    {
        /**
         * $this->_fleet->count() це нудно; давайте опишемо SPL Countable інтерфейс
         */
        $this->assertEquals(0, count($this->_fleet));
    }
 
    public function testAddingAShipWillIncrementCountByOne()
    {
        $this->_fleet->addShip('USS Enterprise');
        $this->assertEquals(1, count($this->_fleet));
    }
 
    public function testAfterAddingAShipWeCanRetrieveItsNameByIndex()
    {
        $this->_fleet->addShip('USS Enterprise');
        $this->assertEquals('USS Enterprise', $this->_fleet->getShip( count($this->_fleet) - 1 ));
    }
}

Розглянуті тестові випадки це гарний маленький початок. Ми описали кілька методів setUp () і tearDown (). В SimpleTest і в PHPUnit вони використовуються для створення фікстур (fixtures). Фікстура - це певний ресурс, що містить всі тести, які мають загальне в умовах тесту і які встановлюють контекст тесту (тестову ситуацію) таким же, як і інші об'єкти або ресурси, що повторюються. Оскільки кожен тест повинен бути ізольований (не може ділитися інформацією), ці методи будуть говорити фрейморку створювати наші фікстури (сутність My_Fleet) перед кожним тестом, і знищувати їх після. Отже, кожен тест буде отримувати новеньку версію для того, щоб грати з нею, позбавлену всього того, що могли зробити тести, які виконувалися раніше. Всі вищевказані тести є публічними методами, імена яких починаються з «test». Все що запускається без «test» не буде включено в звіт (якщо тести запускаються під PHPUnit). Ви можете використовувати це для створення хелпер методів для установки тестів, не піклуючись при цьому, що дані методи будуть розцінені фрейморвком як окремі тести. Хелпер методи це досить зручно для повторюваних задач, тому що навіть тести можуть піддаватися рефакторінгу. Ім'я класу, за домовленістю, закінчується на «Test». Всередині кожного тесту ми маємо звернення до методів «ассерт». Ассерти просто беруть очікувані значення і порівнюють їх з тим, які були отримані. Якщо очікувані значення не збігаються з фактичними, тоді тест буде провалено. Знання про ассерти в ваших тестах - це вже 90% від всієї справи. Решта 10% - це впевненість, що кожен тест повністю ізольований від інших (використовуйте фікстури та імітаційні об'єкти, доступні інструменти для цього). Я використовую тільки вищезгаданий assertEquals (), але повний список для PHPUnit доступний тут.
Зараз ми не розглядаємо імітаційні (mock) об'єкти, але цей компонент є дуже важливим у побудові ізольованості модульного тесту від усіх інших класів і ресурсів, крім тестуємого.

Запуск тестів
Запуск тестів PHPUnit може бути здійснений з консолі (навіть MS-DOS на Windows Vista) або веб-браузері. Щоб зробити це просто, ми зупинимося на швидкому запуску команд через консоль, де ми зберігаємо цей клас тесту. PHPUnit також описує методи організації тестів в блоки, які не розглядаються тут, але які можуть бути дуже необхідні, якщо ви не хочете запускати всі тести один за одним цілу вічність.
Для запуску нашого єдиного класу тесту, відкрийте консоль і перейдіть в місце, де зберігається тест. Консольна команда проста:
phpunit MyFleetTest
Ім'я тесту буде відображено в імені збереженого файлу, значить клас MyFleetTest повинен бути збережен як файл MyFleetTest.php. Вперед, запускайте тест прямо зараз. Я заздалегідь попереджаю вас, що він буде, ясна річ, провалено, тому що ми до сих пір не отримали вказівки що до коду класу! Але зараз все буде ...

Модульне тестування та розробка через тестування
Можливо, ви вже помітили цю невелику проблему, яка існує на даний момент. Ми написали деякі тести. Але де ж тестується фактичний клас? Можна з впевненістю сказати, що ми могли б написати клас і згодом тестувати його (цілком нормальна практика в PHP), але для більш широкої перспективи, я не став цього робити.
Один з популярних способів використання модульного тестування - це практика розробки через тестування (TDD). TDD це необов'язковий компонент модульного тестування, скоріше додаткова практика, яку використовує модульне тестування з тих пір, як це доступний стандарт для написання запускаємих додатків. Ідея, що стоїть за TDD, полягає в описі поведінки класів в коді, що завантажується (тобто тестах) перед написанням коду, це передбачає інструмент для керування тим, як клас повинен бути оформлений. Це поклало початок для кличу «Тести в першу чергу». І, отже, до популяції «заражених тестом». Їм варто зняти фільм жахів якось.
Судячи з тестів, які ми тільки що написали. У написанні тестів до написання коду, ми були змушені зробити декілька речей. В першу чергу, ми придумали відкрите API класу перед усім іншим. Слід зазначити, в модульному тестуванні та TDD, безглуздо тестувати приватні методи (звані "Testing State"), так як ми рідше цікавимося тим, як код щось зробив, у порівнянні з тим який повинен бути кінцевий результат (орієнтуємося на результати, а не на проміжні стани). У купі коду результат залишається тим же, але робочий код з часом буде збільшуватися, у відповідності з рефакторінгом, новою функціональністю PHP або в залежності від вимог системи - значить, тестування всіх цих речей тільки змушує нас постійно переписувати наші тести з неповажних причин.
Тепер, визначивши відкрите API, ми перебуваємо на ранній стадії проектування. Ми фактично не тестуємо на собі (адже в нас до сих пір немає коду!). Замість цього ми описуємо наші сподівання про те, як клас повинен працювати, а потім пишемо код, який працює як ми описували.
Колись ми прийдемо до фактичного написання коду, і вже будемо мати всю виконану роботу по проектуванню і налаштуванню тестів, які в подальшому будуть перевіряти новий код, який ми пишемо. Отже, поки TDD є методом проектування, він, як і раніше, надає гарний набір тестів. Отже, давайте все-таки напишемо наш клас.
Прибрати підсвітку коду
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?php
 
class My_Fleet implements Countable
{
    protected $_ships = array();
 
    public function addShip($shipName)
    {
        $this->_ships[] = $shipName;
    }
 
    public function count()
    {
        return count($this->_ships);
    }
 
    public function getShip($index)
    {
        return $this->_ships[ intval($index) ];
    }
}

Працюючий клас і всі наші тести пройдуть успішно! Можливо, пізніше ми змінимо тести і дозволимо об'єктам Ship, які описують __toString(), виводити ім'я корабля. Невелика зміна у тестах в strval() повертає значення getShip() і наші тести будуть оновлені для цієї зміненої поведінки.

Оригінал: An Introduction to the Art of Unit Testing in PHP

Рейтинг: 12345   << Ви можете поставити оцінку цій статті


Подібні статті:
   6 інструментів для того щоб бути ефективним Web-розробником
   Розуміння області видимості в об’єктно-орієнтованому JavaScript
   Інтеграція FCKeditor в Zend_Form
   Автоматизоване тестування з використанням Zend Framework
   Паттерн кешування для моделей


 
 

Залишити коментар:

Ім'я


E-mail


Повідомлення