Как написать unit тест php

Время на прочтение
13 мин

Количество просмотров 180K

Язык PHP очень легок для изучения. Это, а так же обилие литературы «Освой _что_угодно_ за 24 часа» породило большое количество, мягко говоря, некачественного кода. Как следствие, рано или поздно любой программист, который выходит за рамки создания гостевой книги или сайта-визитки сталкивается с вопросом: «а если я здесь немножко добавлю, все остальное не ляжет?» Дать ответ на этот вопрос и на многие другие может юнит-тестирование.

В самом начале хочется оговориться — здесь речь не будет идти о TDD и методологиях разработки ПО. В данной статье я попробую показать начинающему PHP-разработчику основы использования модульного тестирования на базе фреймворка PHPUnit

Вместо предисловия

Вначале возникает вполне резонный вопрос: А зачем, если все и так работает?
Здесь все просто. После очередного изменения что-то перестанет работать так как надо — это я вам обещаю. И тогда поиск ошибки может отнять очень много времени. Модульное тестирование может свести этот процесс к считанным минутам. Не будем так же исключать переезд на другую платформу и связанные с ним «подводные камни». Чего только стоит разность в точности вычислений на 64- и 32-разрядных системах. А когда-то вы в первый раз столкнетесь с нюансами вроде

<?php
print (int)((0.1 + 0.7) * 10);
// думаете 8? проверьте ...
// или лучше так: "Вы еще не используете BC Math? Тогда мы идем к вам!"

Если вопрос необходимости отпал, то можно приступить к выбору инструмента. Здесь ассортимент в общем-то невелик — PHPUnit (http://www.phpunit.de/) и SimpleTest (http://www.simpletest.org/). Поскольку PHPUnit уже стал стандартом де-факто в тестировании PHP приложений, то на нем и остановимся.

Первое знакомство

Вопросы установки рассматривать не будем: все достаточно внятно изложено на сайте. Попробуем лучше понять, как это все работает.

Допустим, есть у нас некий класс «MyClass», одним из методов реализующий возведение числа в степень. (Здесь вынужден извиниться, но все примеры, в общем-то, высосаны из пальца)

MyClass.php

<?php
class MyClass {public function power($x, $y)
    {
        return pow($x, $y);
    }
}

Хочется проверить, правильно ли он работает. О всем классе речь пока не идет — только об одном методе. Напишем для проверки такой тест.

MyClassTest.php

<?php
require_once 'PHPUnit/Framework.php';
require_once 'MyClass.php';class MyClassTest extends PHPUnit_Framework_TestCase {
    public function testPower()
    {
        $my = new MyClass();
        $this->assertEquals(8, $my->power(2, 3));
 }
}

Небольшое отступление о формате тестов.

• Название класса в тесте складывается из названия тестируемого класса плюс «Test»;
• Класс для тестирования в большинстве случаев наследуется от PHPUnit_Framework_TestCase;
• Каждый тест является паблик-методом, название которого начинается с префикса «test»;
• Внутри теста мы используем один из assert-методов для выяснения соответствует ли результат обработки ожидаемому (подробнее чуть ниже);

Теперь глядя на тест мы можем понять, что тестируя метод возведения в степень мы создаем экземпляр класса, вызываем нужный нам метод с заранее определенными значениями и проверяем правильно ли были проведены вычисления. Для этой проверки был использован метод assertEquals(), который первым обязательным параметром принимает ожидаемое значение, вторым актуальное и проверяет их соответствие. Размяв мозги и освежив в памяти знания таблицы умножения, мы предположили, что 2³=8. На этих данных мы и проверим, как работает наш метод.
Запускаем тест:

$ phpunit MyClassTest
.
Time: 0 seconds
OK (1 test, 1 assertion)

Результат выполнения теста «ОК». Казалось бы можно остановиться на этом, но иногда было бы неплохо для проверки скормить методу не один набор данных. PHPUnit предоставляет нам такую возможность — это провайдеры данных. Провайдер данных тоже является паблик-методом (название не существенно), который возвращает массив наборов данных для каждой итеррации. Для использования провайдера необходимо указать его в теге @dataProvider к тесту.

Изменим наш тест следующим образом:

MyClassTest.php

<?php
require_once 'PHPUnit/Framework.php';
require_once 'MyClass.php';class MyClassTest extends PHPUnit_Framework_TestCase {/**
    * @dataProvider providerPower
    */
    public function testPower($a, $b, $c)
    {
        $my = new MyClass();
        $this->assertEquals($c, $my->power($a, $b));
    }public function providerPower ()
    {
        return array (
            array (2, 2, 4),
            array (2, 3, 9),
            array (3, 5, 243)
        );
    }
}

После запуска увидим следующую картину:

.F.
Time: 0 seconds
There was 1 failure:
1) testPower(MyClassTest) with data set #1 (2, 3, 9)
Failed asserting that <integer:8> matches expected value <integer:9>.
/home/user/unit/MyClassTest.php:14
FAILURES!
Tests: 3, Assertions: 3, Failures: 1.

Опишу подробнее. Точка, которую в первом выводе теста многие могли принять за опечатку на самом деле таковой не является — это успешно пройденный тест. F(ailure) — соответственно тест не пройденный. Значит в данном случае, было проведено 3 теста, один из который завершился неудачно. В расширенном описании нам было сказано, какой именно, с каким набором исходных данных, с каким реальным и каким ожидаемым результатом. Если бы 2³ действительно равнялось 9-ти, то мы увидели бы таким образом ошибку в нашем сценарии.

Здесь, как мне кажется, есть смысл отвлечься от несколько абстрактной практики и перейти ко вполне конкретной теории. А именно, описать какими же assert-методами мы располагаем для проверки поведения тестируемых сценариев.

Два самых простых — это assertFalse() и assertTrue(). Проверяют, является ли полученное значение false и true соответственно. Далее идут уже упомянутый assertEquals() и обратный ему assertNotEquals(). В их использовании есть нюансы. Так при сравнении чисел с плавающей точкой есть возможность указать точность сравнения. Так же эти методы используются для сравнения экземпляров класса DOMDocument, массивов и любых объектов (в последнем случае равенство будет установлено, если атрибуты объектов содержат одинаковые значения). Так же следует упомянуть assertNull() и assertNotNull() которые проверяют соответствие параметра типу данных NULL (да-да, не забываем, что в PHP это отдельный тип данных). Этим возможные сравнения не ограничиваются. Нет смысла в рамках этой статьи заниматься перепечаткой документации, потому приведу по возможности структурированный список всех возможных методов. Более детально интересующиеся могут прочитать здесь

Базовые методы сравнения

assertTrue() / assertFalse()
assertEquals() / assertNotEquals()
assertGreaterThan()
assertGreaterThanOrEqual()
assertLessThan()
assertLessThanOrEqual()
assertNull() / assertNotNull()
assertType() / assertNotType()
assertSame() / assertNotSame()
assertRegExp() / assertNotRegExp()

Методы сравнения массивов

assertArrayHasKey() / assertArrayNotHasKey()
assertContains() / assertNotContains()
assertContainsOnly() / assertNotContainsOnly()

ООП специфичные методы

assertClassHasAttribute() / assertClassNotHasAttribute()
assertClassHasStaticAttribute() / assertClassNotHasStaticAttribute()
assertAttributeContains() / assertAttributeNotContains()
assertObjectHasAttribute() / assertObjectNotHasAttribute()
assertAttributeGreaterThan()
assertAttributeGreaterThanOrEqual()
assertAttributeLessThan()
assertAttributeLessThanOrEqual()

Методы сравнения файлов

assertFileEquals() / assertFileNotEquals()
assertFileExists() / assertFileNotExists()
assertStringEqualsFile() / assertStringNotEqualsFile()

Методы сравнения XML

assertEqualXMLStructure()
assertXmlFileEqualsXmlFile() / assertXmlFileNotEqualsXmlFile()
assertXmlStringEqualsXmlFile() / assertXmlStringNotEqualsXmlFile()
assertXmlStringEqualsXmlString() / assertXmlStringNotEqualsXmlString()

Разное

assertTag()
assertThat()

Исключения

Если еще не надоело, то вернемся к практике, а именно к обработке исключений. Для начала модифицируем наш тестируемый класс — введем в него метод, который будет это исключение выбрасывать.

MyClass.php

<?php
class MathException extends Exception {};class MyClass {// ...public function divide($x, $y)
    {
        if (!(boolean)$y)
        {
            throw new MathException('Division by zero');
        }
        return $x / $y;
    }
}

Теперь надо создать тест, который будет завершаться успешно в том случае, если при определенном наборе данных будет вызвано это исключение. Задать требуемое исключение можно как минимум двумя способами — добавив к тесту @expectedException либо вызвав в тесте метод setExpectedException().

MyClassTest.php

<?php
require_once 'PHPUnit/Framework.php';
require_once 'MyClass.php';class MyClassTest extends PHPUnit_Framework_TestCase {// .../**
    * @expectedException MathException
    */
    public function testDivision1()
    {
        $my = new MyClass();
        $my->divide (8, 0);
    }public function testDivision2 ()
    {
        $this->setExpectedException('MathException');
        $my = new MyClass();
        $my->divide(8, 0);
    }
}

Тесты, в общем-то, абсолютно идентичны. Выбор способа остается на ваше усмотрение. Помимо механизмов предоставляемых непосредственно PHPUnit, для тестирования исключений можно воспользоваться стандартным try {…} catch (), к примеру, так:

MyClassTest.php

<?php
require_once 'PHPUnit/Framework.php';
require_once 'MyClass.php';class MyClassTest extends PHPUnit_Framework_TestCase {// ...public function testDivision3()
    {
        $my = new MyClass();
        try {
            $my->divide (8, 2);
        } catch (MathException $e) {
            return;
        }
        $this->fail ('Not raise an exception');
    }
}

В этом примере мы так же видим не рассмотренный ранее способ завершения теста с помощью вызова метода fail(). Вывод теста будет следующим:

F
Time: 0 seconds
There was 1 failure:
1) testDivision3(MyClassTest)
Not raise an exception
/home/user/unit/MyClassTest.php:50

Принадлежности

Базовые методы тестирования мы освоили. Можно ли улучшить наш тест? Да. Написанный c начала этой статьи класс проводит несколько тестов, в каждом из которых создается экземпляр тестируемого класса, что абсолютно излишне, потому как PHPUnit предоставляет в наше пользование механизм принадлежностей теста (fixtures). Установить их можно защищенным методом setUp(), который вызывается один раз перед началом каждого теста. После окончания теста вызывается метод tearDown(), в котором мы можем провести «сборку мусора». Таким образом, исправленный тест может выглядеть так:

MyClassTest.php

<?php
require_once 'PHPUnit/Framework.php';
require_once 'MyClass.php';class MyClassTest extends PHPUnit_Framework_TestCase {

    protected

$fixture;

    protected

function setUp()
    {
        $this->fixture = new MyClass ();
    }

    protected

function tearDown()
    {
        $this->fixture = NULL;
    }/**
    * @dataProvider providerPower
    */
    public function testPower($a, $b, $c)
    {
        $this->assertEquals($c, $this->fixture->power($a, $b));
    }public function providerPower()
    {
        return array(
            array(2, 2, 4),
            array(2, 3, 8),
            array(3, 5, 243)
        );
    }// …}

Наборы тестов

После того, как код нескольких классов будет покрыт тестами, становится довольно таки неудобно запускать каждый тест по отдельности. Здесь нам на помощь могут прийти наборы тестов — несколько связанных единой задачей тестов можно объединить в набор и запускать соответственно его. Наборы реализованы классом PHPUnit_Framework_TestSuite. Необходимо создать экземпляр этого класса и добавить в него необходимые тесты с помощью метода addTestSuite(). Так же с помощью метода addTest() возможно добавление другого набора.

SpecificTests.php

<?php
require_once 'PHPUnit/Framework.php';
// подключаем файлы с тестами
require_once 'MyClassTest.php';class SpecificTests
{
    public static function suite()
    {
        $suite = new PHPUnit_Framework_TestSuite('MySuite');
        // добавляем тест в набор
        $suite->addTestSuite('MyClassTest');
        return $suite;
    }
}

AllTests.php

<?php
require_once 'PHPUnit/Framework.php';
// подключаем файл с набором тестов
require_once 'SpecificTests.php';class AllTests
{
    public static function suite()
    {
        $suite = new PHPUnit_Framework_TestSuite('AllMySuite');
        // добавляем набор тестов
        $suite->addTest(SpecificTests::suite());
        return $suite;
    }
}

А теперь представим себе набор тестов для сценария, работающего с БД. Неужели нам в каждом тесте придется подключаться к базе? Нет — не придется. Для этого можно создать свой класс унаследованный от PHPUnit_Framework_TestSuite, определить его методы setUp() и tearDown() для инициализации интерфейса БД и просто передать его в тест атрибутом sharedFixture. Базы данных мы оставим на потом, а пока попробуем создать собственный набор тестов для уже имеющегося класса.

MyClassTest.php

<?php
require_once 'PHPUnit/Framework.php';
require_once 'MyClass.php';class MyClassTest extends PHPUnit_Framework_TestCase {

   
    protected

$fixture;

    protected

function setUp()
    {
        $this->fixture = $this->sharedFixture;
    }

    protected

function tearDown()
    {
        $this->fixture = NULL;
    }/**
    * @dataProvider providerPower
    */
    public function testPower ($a, $b, $c)
    {
        $this->assertEquals($c, $this->fixture->power($a, $b));
    }public function providerPower()
    {
        return array(
            array(2, 2, 4),
            array(2, 3, 8),
            array(3, 5, 243)
        );
    }// …}

MySuite.php

<?php
require_once 'MyClassTest.php';class MySuite extends PHPUnit_Framework_TestSuite {

    protected

$sharedFixture;public static function suite()
    {
        $suite = new MySuite('MyTests');
        $suite->addTestSuite('MyClassTest');
        return $suite;
    }

    protected

function setUp()
    {
        $this->sharedFixture = new MyClass();
    }

    protected

function tearDown()
    {
        $this->sharedFixture = NULL;
    }}

Здесь мы в sharedFixture положили экземпляр тестируемого класса, а в тесте просто его использовали — решение не слишком красивое (я бы даже сказал, вообще не красивое), но общее представление о наборах тестов и передаче принадлежностей между тестами оно дает. Если наглядно изобразить очередность вызова методов, то получится нечто вроде такого:

MySuite::setUp()
MyClassTest::setUp()
MyClassTest::testPower()
MyClassTest::tearDown()
MyClassTest::setUp()
MyClassTest::testDivision()
MyClassTest::tearDown()
...
MySuite::tearDown()

Дополнительные возможности

Помимо всего вышеизложенного может возникнуть необходимость проверить не только расчеты и поведение сценария, но так же вывод и скорость отработки. Для этого в наше распоряжение предоставлены расширения PHPUnit_Extensions_OutputTestCase и PHPUnit_Extensions_PerformanceTestCase соответственно. Добавим в наш тестируемый класс еще один метод, и проверим правильно ли он работает.

MyClass.php

<?php
class MyClass {// ...public function square($x)
    {
        sleep(2);
        print $x * $x;
    }}

MyClassTest.php

<?php
require_once 'PHPUnit/Framework.php';
require_once 'PHPUnit/Extensions/OutputTestCase.php';
require_once 'PHPUnit/Extensions/PerformanceTestCase.php';
require_once 'MyClass.php';class MyClassOutputTest extends PHPUnit_Extensions_OutputTestCase {

    protected

$fixture;

    protected

function setUp()
    {
        $this->fixture = $this->sharedFixture;
    }

    protected

function tearDown()
    {
        $this->fixture = NULL;
    }public function testSquare()
    {
        $this->expectOutputString('4');
        $this->fixture->square(2);
    }
}class MyClassPerformanceTest extends PHPUnit_Extensions_PerformanceTestCase {

    protected

$fixture;

    protected

function setUp()
    {
        $this->fixture = $this->sharedFixture;
    }

    protected

function tearDown()
    {
        $this->fixture = NULL;
    }public function testPerformance()
    {
        $this->setMaxRunningTime(1);
        $this->fixture->square(4);
    }
}class MyClassTest extends PHPUnit_Framework_TestCase {// …}

Задать ожидаемый вывод сценария можно с помощью методов expectOutputString() или expectOutputRegex(). А для метода setMaxRunningTime() планируемое время отработки указывается в секундах. Для того, что бы эти тесты запускались вместе с уже написанными их всего лишь надо добавить к нашему набору:

MySuite.php

<?php
require_once 'MyClassTest.php';class MySuite extends PHPUnit_Framework_TestSuite {

    protected

$sharedFixture;public static function suite()
    {
        $suite = new MySuite('MyTests');
        $suite->addTestSuite('MyClassTest');
        $suite->addTestSuite('MyClassOutputTest');
        $suite->addTestSuite('MyClassPerformanceTest');
        return $suite;
    }// ...}

Пропускаем тесты

И напоследок рассмотрим ситуацию, в которой некоторые тесты необходимо пропускать по каким либо причинам. К примеру в том случае, когда на тестируемой машине отсутствует какое-либо расширение PHP, можно убедившись в его отсутствии пометить тест, как пропущенный добавив к его коду следующее:

if (!extension_loaded('someExtension')) {
    $this->markTestSkipped('Extension is not loaded.');
}

Либо в том случае, когда тест написан для кода, которого еще нет в сценарии (не редкая для TDD ситуация) его можно пометить как не реализованный с помощью метода markTestIncomplete()

Напоследок

Наверное, на этом пока можно остановиться. Тема модульного тестирования данной статьей далеко не завершена — осталось еще использование mock-объектов, тестирование работы с БД, анализ покрытия кода и многое другое. Но надеюсь, что поставленная цель — ознакомить начинающих с базовыми возможностями PHPUnit и подтолкнуть к использованию юнит-тестов, как одному из средств для достижения большей эффективности — была достигнута.
Удачи вам, и стабильных приложений.

Это первая часть серии «PHPUnit для начинающих». В этом руководстве мы объясним для чего покрывать код unit-тестами и всю мощь инструмента PHPUnit. В конце мы напишем простой тест с использованием PHPUnit.

• PHPUnit  для начинающих. Часть 1: Начните использование.
• PHPUnit для начинающих. Часть 2: Data Provider.
• PHPUnit для начинающих. Часть 3: Тестовые «двойники»

Типы тестов

Прежде чем мы погрузимся в PHPUnit давайте разберём различные типы тестов. В зависимости от того, как вы хотите категоризировать их, в PHPUnit применяются любые типы тестов для разработки ПО.

Давайте разделим тесты на категории по уровню их специфичности. По данным Википедии. В целом существует 4 признанных уровня тестов:

• Unit-тестирование (модульное): этот уровень тестирует наименьшую единицу функциональности.
  С точки зрения разработчика его задачей является убедиться, что тестируемая функция выполняет именно то, для чего она реализована. Таким образом, она должна быть минимально зависима или совершенно независима от другой функции или класса. Она должна быть написана таким образом, чтобы она полностью выполнялась в памяти, т.е. она не должна коннектиться к БД, не должна обращаться к сети или использовать ФС и т.д. Unit-тестирование должно быть как можно более простым.
• Интеграционное тестирование: этот уровень «соединяет» разные единицы кода и тестирует правильно ли работают их комбинации. Он надстраивается сверху над unit-тестированием и способен отловить баги, которые нельзя выявить с помощью unit-тестирования, т.к. интеграционное тестирование проверяет, работает ли класс А с классом Б.
• Системное тестирование: оно создано для воспроизведения работы сценариев в условиях, приближенных к боевым. Оно, в свою очередь, надстраивается сверху над интеграционным тестированием. В то время как интеграционное тестирование обеспечивает слаженную работу различных частей системы. Системное тестирование отвечает за то, что система работает так, как предполагает пользователь, прежде чем отправить её следующий уровень.
• Приёмочное тестирование: в то время как выше приведённые тесты предназначены для разработчиков на стадии разработки, приёмочное тестирование фактически выполняется пользователями ПО. Пользователей не интересуют внутренние особенности ПО, их интересует только как работает это ПО.

Если мы поместим типы тестов в пирамиду, выглядеть это будет так:

Что такое PHPUnit

Глядя на пирамиду вверху, мы можем сказать, что юнит-тестирование — это строительный материал для всех остальных видов тестирования. Когда мы закладываем сильную базу, мы способны построить устойчивое приложение. Однако написание тестов вручную, а также запуск тестов каждый раз когда вы вносите изменения — это процесс трудоёмкий. Если бы существовал инструмент для автоматизации этого процесса, то написание тестов стало бы гораздо более приятным занятием.

Вот где выходит на сцену PHPUnit. В настоящее время PHPUnit наиболее популярный фреймворк для юнит-тестирования в PHP. Кроме наличия таких возможностей, как моки (подделки) объектов, он также может анализировать покрытие кода, логирование и предоставляет тысячи других возможностей.

Давайте установим PHPUnit в нашей системе:

1. Загрузите его: PHPUnit распространяется в PHAR(PHp ARhive) файле. Скачать можно здесь.
2. Добавьте путь к нему в системную переменную $PATH: после скачивания PHAR файла, убедитесь, что он является запускаемым (executable) и путь, где он находится, прописан в системной переменной $PATH. Т.о. вы сможете запускать его из любого места.

Если вы работаете на Unix-подобной системе, то это вы можете сделать следующими командами:

$ wget https://phar.phpunit.de/phpunit.phar

$ chmod +x phpunit.phar

$ sudo mv phpunit.phar /usr/local/bin/phpunit

Если вы сделали всё верно, то вы сможете увидеть версию установленного PHPUnit, набрав в вашем терминале команду:

$ phpunit --version

Ваш первый unit-тест

Пришло время написать ваш первый unit-тест! Для начала нам нужен какой-нибудь класс, который мы будем тестировать. Давайте напишем простенький класс под названием Calculator. И напишем для него тест.

Создайте файл "Calculator.php" и скопируйте в него нижеприведённый код. Этот класс Calculator имеет только один метод add.

class Calculator
{
 
    public function add($a, $b)
    {
        return $a + $b;
    }
 
}

Теперь создайте файл для тестов "CalculatorTest.php" и скопируйте в него следующий код. Мы остановимся на каждом методе более детально.

require 'Calculator.php';
 
class CalculatorTests extends PHPUnit_Framework_TestCase
{
    private $calculator;
 
    protected function setUp()
    {
        $this->calculator = new Calculator();
    }
 
    protected function tearDown()
    {
        $this->calculator = NULL;
    }
 
    public function testAdd()
    {
        $result = $this->calculator->add(1, 2);
        $this->assertEquals(3, $result);
    }
 
}

• Line 2: подключаем файл тестируемого класса Calculator.php. Так как в этом файле мы собираемся тестировать именно этот класс, убедитесь, что он подключен.
• Line 8: setUp() это метод, который вызывается перед каждым тестом. Запомните он вызывается перед Каждым тестом, что означает, что если вы добавите ещё один метод теста в этот класс, то он будет вызываться и перед ним тоже.
• Line 13: аналогично методу setUp(), tearDown() вызывается после каждого теста.
• Line 18: testAdd() — это метод-тест для метода add(). PHPUnit будет распознавать каждый метод, начинающийся с test, как метод-тест и автоматически запускать его. В действительности этот метод очень прост: сначала мы вызываем метод Calculator::add() чтобы вычислить значение 1 плюс 2, а затем мы проверяем, что этот метод вернул правильное значение, используя assertEquals() из PHPUnit.

Заключительной частью проделанной работы является запуск PHPUnit и проверка, что все тесты проходят (выполняются без ошибок). В вашем терминале зайдите в директорию где вы создали файл с тестами и запустите следующую команду:

$ phpunit CalculatorTest.php

Если вы всё сделали правильно, то вы должны увидеть что-то вроде этого:

PHPUnit 3.7.32 by Sebastian Bergmann.

.

Time: 31ms, Memory: 2.25Mb

OK (1 test, 1 assertion)

Заключение

Мы завершили первое руководство из серии «PHPUnit для начинающих». В следующей статье мы собираемся показать вам как использовать Data Provider (поставщик данных) в ваших тестах.

Надеемся это простое руководство поможет вам в вашей разработке и поможет начать использовать unit-тестирование.

Если вам понравился перевод на эту тему читайте нас в Twitter, подписывайтесь на наши группы в Facebook, ВКонтакте, Google+. Мы будем рады продолжить серию.