Юнит-тестирование с PHPUnit: начало работы с PHP-тестами

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

Конечно, чтобы эффективно использовать PHPUnit, важно иметь твердую базу знаний PHP и понимать основные принципы программирования. Если вы чувствуете, что вам не хватает базовых знаний или хотите углубить свое понимание PHP, обратите внимание на подборку лучших PHP-курсов, где вы найдете образовательные программы различного уровня сложности. А теперь вернемся к нашему разговору о тестировании.

PHPUnit — это фреймворк для автоматизированного тестирования PHP-кода, который позволяет нам, гордым обитателям мира веб-разработки, сохранять рассудок и репутацию. Он дает возможность писать тесты, которые проверяют работоспособность нашего кода, не прибегая к древним методам вроде жертвоприношений или гадания на кофейной гуще.

Почему же PHPUnit так популярен среди разработчиков? Возможно, потому что он позволяет нам спать спокойно, зная, что наш код не развалится от легкого дуновения ветра. Или потому, что он помогает обнаружить ошибки до того, как их обнаружат пользователи (и наш босс). В любом случае, PHPUnit — это тот инструмент, без которого современная PHP-разработка была бы… ну, скажем так, менее предсказуемой.

Установка и настройка PHPUnit

Установка и настройка PHPUnit — это как сборка шведской мебели, только без симпатичных картинок и с большим количеством командной строки. Но не волнуйтесь, я проведу вас через этот лабиринт технических терминов и загадочных команд.

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

Теперь о структуре проекта. Представьте, что ваш код — это город, а тесты — это служба контроля качества этого города. Вы же не хотите, чтобы инспекторы жили в одних домах с обычными жителями, верно? Поэтому мы создаем отдельные районы: src для кода и tests для тестов. Это как зонирование в градостроительстве, только без утомительных заседаний городского совета.

Но давайте углубимся в детали. Ведь, как говорится, дьявол (и удовольствие от программирования) кроется именно в них.

Установка через Composer

Итак, вы готовы пригласить PHPUnit на вечеринку вашего проекта? Отлично! Откройте свой любимый терминал (да-да, тот самый черный экран, который пугает не-программистов) и введите следующую команду:

composer require --dev phpunit/phpunit ^9.5

Эта магическая формула призовет PHPUnit версии 9.5 или выше в ваш проект. Флаг —dev говорит Composer’у, что это зелье нужно только для разработки, а не для боевого применения.

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

Настройка автозагрузки

Автозагрузка — это как GPS для вашего кода. Без нее классы будут бродить в потемках, натыкаясь друг на друга и создавая хаос.

Откройте файл composer.json (если вы его еще не создали, самое время это сделать) и добавьте следующие строки:

"autoload": {
    "psr-4": {
    	"MyApp\\": "src/"
    }
},
"autoload-dev": {
    "psr-4": {
    	"MyApp\\Tests\\": "tests/"
    }
}

Это говорит Composer’у: «Эй, дружище, когда ты увидишь класс с пространством имен MyApp, ищи его в папке src. А если это тест — то в папке tests».

После этого не забудьте выполнить команду composer dump-autoload, чтобы Composer перестроил карту автозагрузки. Теперь ваши классы и тесты смогут найти друг друга, как влюбленные в романтической комедии. Только с меньшим количеством неловких моментов и большим количеством юнит-тестов.

Создание и написание тестов в PHPUnit

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

Основной принцип написания тестов в PHPUnit прост: мы создаем класс, который наследуется от TestCase, и наполняем его методами, начинающимися со слова test. Звучит просто, не так ли? Ну, примерно как «просто напишите бестселлер» или «просто создайте многомиллиардную компанию». Дьявол, как всегда, кроется в деталях.

В каждом тестовом методе мы обычно делаем три вещи: подготавливаем данные, выполняем действие и проверяем результат. Это как готовить обед: сначала выбираем ингредиенты, потом готовим блюдо, а в конце пробуем и решаем, съедобно ли оно. Только в нашем случае вместо еды — код, а вместо дегустации — утверждения (assertions).

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

Структура тестового класса

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

use PHPUnit\Framework\TestCase;

class SuperHeroTest extends TestCase
{
    public function testCanFly()
    {
    	// Здесь будет наш тест
    }

    public function testHasSuperstrenght()
    {
    	// И здесь тоже
    }
}

Заметьте, что наш класс SuperHeroTest наследуется от TestCase. Это как получить суперспособности от PHPUnit. Теперь мы можем использовать все крутые методы для тестирования, которые предоставляет PHPUnit.

Методы в этом классе начинаются со слова test. Это не просто причуда PHPUnit — это как носить плащ для супергероя. Без этого префикса PHPUnit просто не распознает метод как тест и пропустит его, как Супермен пропускает обычных преступников в поисках суперзлодея.

Часто используемые методы PHPUnit

А теперь давайте поговорим о суперспособностях, которые дает нам PHPUnit. Вот несколько самых полезных:

• assertEquals($expected, $actual) — проверяет, равны ли два значения. Это как сравнить две фотографии и убедиться, что они идентичны.
• assertTrue($condition) и assertFalse($condition) — проверяют, истинно или ложно утверждение. Это как детектор лжи, только для кода.
• assertContains($needle, $haystack) — проверяет, содержится ли элемент в массиве или строке. Представьте, что вы ищете иголку в стоге сена, только PHPUnit делает это за вас.
• assertInstanceOf($expected, $actual) — проверяет, является ли объект экземпляром определенного класса. Это как проверить, действительно ли человек в костюме Бэтмена — это Бэтмен, а не просто косплеер.

Использовать их просто. Например:

public function testSupermanCanFly()
{
    $superman = new Superhero('Superman');
    $this->assertTrue($superman->canFly(), 'Кажется, наш Супермен разучился летать!');
}

Помните, что каждый раз, когда вы используете эти методы, вы как бы бросаете вызов своему коду. «Ну-ка, покажи, на что ты способен!» — говорите вы. И если код не оправдывает ваших ожиданий, PHPUnit сообщит об этом. Громко и (иногда) не очень вежливо.

Примеры тестов: от простых к сложным

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

Тестирование методов классов

Представьте, что у нас есть класс Calculator. Да-да, тот самый калькулятор, который каждый начинающий программист создает, чтобы почувствовать себя Тони Старком. Давайте протестируем его:

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

class CalculatorTest extends TestCase
{
    public function testAdd()
    {
    	$calc = new Calculator();
    	$result = $calc->add(2, 3);
    	$this->assertEquals(5, $result, "Кажется, наш калькулятор разучился складывать. Может, он перешел на систему счисления майя?");
    }
}

Здесь мы создаем экземпляр калькулятора, вызываем метод add и проверяем, что 2+3 действительно равно 5. Если это не так, то… ну, у нас проблемы посерьезнее, чем баги в коде.

Тестирование исключений

А теперь давайте представим, что наш калькулятор не любит делить на ноль. Кто бы мог подумать, правда? Протестируем это:

class Calculator

{
    public function divide($a, $b) {
    	if ($b == 0) {
        	throw new InvalidArgumentException("Деление на ноль? Серьезно? Ты пытаешься открыть портал в параллельную вселенную?");
    	}
    	return $a / $b;
    }
}

class CalculatorTest extends TestCase
{
    public function testDivideByZero()
    {
    	$calc = new Calculator();
    	$this->expectException(InvalidArgumentException::class);
    	$calc->divide(5, 0);
    }
}

Здесь мы говорим PHPUnit: «Эй, дружище, сейчас будет исключение, не пугайся». И если исключение не выбрасывается, PHPUnit подниммет тревогу. Как бдительный сосед, который звонит в полицию, если вы слишком тихо смотрите телевизор.

Тестирование сложной логики

Теперь давайте представим, что наш калькулятор стал немного… эксцентричным. Он решил, что будет выдавать результат в римских цифрах, если сумма больше 10. Почему? Потому что мы можем. Вот как мы могли бы это протестировать:

class FancyCalculator
{
    public function addFancy($a, $b) {
        $sum = $a + $b;
        if ($sum > 10) {
            return $this->toRoman($sum);
        }
        return $sum;
    }

    private function toRoman($number) {
        // Представим, что здесь магическим образом происходит конвертация в римские цифры
    }
}

class FancyCalculatorTest extends TestCase
{
    public function testAddFancy()
    {
        $calc = new FancyCalculator();
        $this->assertEquals(7, $calc->addFancy(3, 4), "Кажется, наш калькулятор решил, что 3+4 - это что-то другое. Может, он перешел на двоичную систему?");
        $this->assertEquals("XII", $calc->addFancy(7, 5), "Наш калькулятор забыл свой латынь? Или, может, он решил перейти на клингонский?");
    }
}

Здесь мы проверяем два сценария: когда сумма меньше или равна 10 (обычное поведение) и когда она больше 10 (выдача результата в римских цифрах). Это как проверить, умеет ли наш друг говорить на двух языках — обычном и «после пяти бокалов пива».

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

Запуск тестов и анализ результатов

Запуск тестов — это как нажатие большой красной кнопки в фильме о супергероях. Вы никогда не знаете, спасете ли вы мир или случайно запустите процесс уничтожения человечества. Но не волнуйтесь, в худшем случае вы просто узнаете, что ваш код не так идеален, как вам казалось. (Кажется. По крайней мере, таково моё личное оценочное суждение.)

H3 Запуск тестов из командной строки

Итак, вы готовы встретиться лицом к лицу с суровой правдой о вашем коде? Отлично! Откройте свой любимый терминал (да, тот самый черный экран, который так пугает не-программистов) и введите следующую команду:

./vendor/bin/phpunit

Эта волшебная формула запустит все тесты в вашем проекте. Но постойте, что если вы хотите запустить только конкретный тест? Может быть, вы не готовы узнать всю правду сразу? Нет проблем! Просто укажите путь к конкретному файлу с тестами:

./vendor/bin/phpunit tests/Unit/SuperCalculatorTest.php

А если вы чувствуете себя особенно храбрым и хотите увидеть все детали процесса тестирования, добавьте флаг —verbose:

./vendor/bin/phpunit --verbose

Теперь PHPUnit расскажет вам все. Абсолютно все. Даже то, о чем вы, возможно, не хотели знать.

Интерпретация результатов тестирования

Итак, вы нажали на «большую красную кнопку», и теперь перед вами поток информации. Что же все это значит? Давайте разберемся.

Если вы видите что-то вроде этого:

OK (3 tests, 5 assertions)

Поздравляю! Ваш код работает именно так, как вы ожидали. Можете открыть шампанское… или хотя бы газировку. Вы заслужили.

Но что, если вы видите что-то такое:

FAILURES!
Tests: 4, Assertions: 6, Failures: 1, Errors: 1

Ох. Кажется, у нас проблемы. Не паникуйте! Это всего лишь значит, что ваш код немного… эксцентричен. Он не делает то, что вы от него ожидаете. Но это не конец света (если только ваш код не управляет ядерным реактором, в этом случае, пожалуйста, паникуйте).

PHPUnit любезно предоставит вам подробную информацию о каждом провалившемся тесте. Например:

1) SuperCalculatorTest::testAddition
Failed asserting that 5 matches expected 6.

/path/to/your/test/SuperCalculatorTest.php:23

Это означает, что в файле SuperCalculatorTest.php, в строке 23, вы ожидали получить 6, а получили 5. Может быть, ваш суперкалькулятор решил, что 2 + 2 = 5? Кажется, он перечитал «1984» Оруэлла.

Помните, что ошибки в тестах — это не повод для расстройства. Это возможность сделать ваш код лучше. Или, по крайней мере, так говорят психологи программистов.

И не забывайте главное правило интерпретации результатов тестов: если все тесты прошли успешно, это не значит, что в вашем коде нет ошибок. Это просто значит, что вы еще не написали достаточно тестов, чтобы их найти. Оптимизм — великая вещь, не правда ли?

Советы по написанию эффективных тестов

Написание эффективных тестов — это как готовка изысканного блюда. Вроде бы и ингредиенты те же, но почему-то у шеф-повара получается шедевр, а у вас — нечто, напоминающее последствия природной катастрофы. Но не отчаивайтесь! Вот несколько советов, которые помогут вам стать если не шеф-поваром, то хотя бы приличным кулинаром в мире тестирования.

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

  Диаграмма, иллюстрирующая независимость тестов

• Принцип «один тест — одна проверка» работает так же хорошо, как принцип «один человек — одна вилка» на званом ужине. Не пытайтесь впихнуть в один тест проверку всего на свете. Это не тест, а полноценный román (и кажется, не из тех, что с хэппи-эндом).
• Названия тестов должны быть говорящими. «testFunction1» говорит о вашем тесте примерно столько же, сколько «еда1» говорит о блюде в меню ресторана. Как насчет «testCalculatorThrowsExceptionOnDivisionByZero»? Длинновато? Возможно. Информативно? Безусловно.
• Не тестируйте приватные методы напрямую. Это все равно что пытаться проверить работу печени, не открывая пациента. Тестируйте публичный интерфейс класса, а приватные методы пусть остаются в тени, как истинные закулисные герои.
• Помните о граничных условиях. Что произойдет, если вы передадите в вашу функцию отрицательное число? А нуль? А число, большее чем unsigned long long int? Да, я знаю, что в PHP нет unsigned long long int. Но вы поняли идею.
• Старайтесь не использовать реальные внешние зависимости в юнит-тестах. База данных, API, файловая система — все это должно быть замоккано. Иначе ваши тесты будут работать медленнее, чем государственные службы, и будут такими же ненадежными.
• Не забывайте о тестировании исключений. Если ваш код должен выбрасывать исключение в определенной ситуации, убедитесь, что он действительно это делает. Иначе вы рискуете получить код, который молча проглатывает ошибки, как удав с проблемами двигательного аппарата.
• И наконец, помните: идеальных тестов не бывает. Как и идеального кода. Как и идеальных программистов (хотя, признайтесь, вы ведь считаете себя исключением?). Стремитесь к совершенству, но не расстраивайтесь, если не достигнете его. В конце концов, даже неидеальные тесты лучше, чем их полное отсутствие.

И напоследок, хочу напомнить: если вы считаете, что написание тестов — это скучно, вы просто делаете это неправильно. Тестирование — это возможность сломать свой код самыми изощренными способами, прежде чем это сделают ваши пользователи. Разве это не весело?

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

Заключение

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

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

Конечно, путь к идеальному набору тестов не будет усыпан розами. Будут моменты, когда вам захочется выбросить свой компьютер в окно, а потом прыгнуть следом за ним. Но не поддавайтесь этому порыву! Во-первых, это может плохо сказаться на вашем здоровье. А во-вторых, после небольшой практики вы поймете, что написание тестов может быть даже… увлекательным. Да-да, я сказал это. Можете цитировать меня.

Так что берите PHPUnit, вооружайтесь терпением и чувством юмора, и отправляйтесь в путь. Пишите тесты, ломайте свой код, чините его, и снова пишите тесты. Помните: каждый проваленный тест — это не поражение, а возможность сделать ваш код лучше. И кто знает, может быть, однажды вы станете тем самым легендарным разработчиком, чьи тесты работают с первого раза. (Хотя, давайте будем реалистами — такого не бывает.)

А теперь идите и тестируйте! И пусть сила PHPUnit будет с вами. Потому что если она не будет с вами, то с вами точно будут баги. А это, поверьте, гораздо менее приятная компания.