✅ Новости WEB и WordPress, темы, плагины. Здесь мы делимся советами и лучшими решениями для веб-сайтов.

Написание модульных тестов с помощью PHPUnit, часть 3: конфигурация XML

38

В предыдущих постах этой серии я затронул следующие две темы:

  1. Написание модульных тестов с помощью PHPUnit, часть 1: настройка. Руководство по началу написания тестов PHPUnit с использованием базового кеша и метода setUp фреймворка.
  2. Написание модульных тестов с помощью PHPUnit, часть 2: разборка. Учебник о том, как писать модульные тесты, которые должным образом используют методы setUp и tearDown PHPUnit.

Каждое из вышеперечисленных предназначено для подготовки к написанию самых простых модульных тестов. Все может усложняться, особенно по мере роста приложения или проекта (но это всегда так, верно?).

Но чтобы убедиться, что кто-то готов к этому, есть еще один последний компонент модульного тестирования, на котором, я считаю, мы должны сосредоточиться, и это понимание XML-файла конфигурации PHPUnit (который вы, возможно, видели в других проектах как phpunit.xml).

XML-конфигурация PHPUnit

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

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

1 Удаление файлов

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

Вот как мы более или менее организуем работу с самого начала проекта:

  • каталог для тестов,
  • файл phpunit.xml _

В итоге вы также увидите:

  • файлы, составляющие проект,
  • тесты, которые проверяют указанные файлы.

Однако на этом этапе давайте взглянем на файл конфигурации XML, а затем попытаемся автоматически запустить PHPUnit без каких-либо других параметров.

2 Основы файла конфигурации

Во-первых, давайте посмотрим на основной файл конфигурации:

<?xml version="1.0" encoding="UTF-8"?>

<!-- http://phpunit.de/manual/4.1/en/appendixes.configuration.html -->
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="http://schema.phpunit.de/4.1/phpunit.xsd"
         bootstrap="./tests/bootstrap.php"
         backupGlobals="false"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
>
  <testsuites>
    <testsuite name="AcmeTests">
      <directory>./tests</directory>
    </testsuite>
  </testsuites>

  <logging>
    <log type="coverage-text" target="php://stdout" showUncoveredFiles="true"></log>
  </logging>
</phpunit>

Теперь давайте разберемся, что именно мы рассматриваем (кроме простого XML).

  • . _ Родительский узел выполняет обычную работу по определению схемы для XML-файла, но есть несколько других компонентов, которые нас интересуют:
    • резервное копирование Globals. На самом деле это связано с аннотацией, которую мы можем сделать в нашем исходном коде. Глобальные переменные — это то, чего мы должны стараться избегать в объектно-ориентированном программировании, но если вы решите использовать их или вам нужно их использовать, тогда PHPUnit скажет обработать значения, поддерживаемые глобальными переменными (и даст вам возможность восстановить их). Я обычно оставляю это как есть.
    • бутстрап. Это необязательно, но если вы решите включить в свои тесты другие файлы (например, привнести фиктивную библиотеку, часть WordPress или стороннюю библиотеку), то это все, что вам нужно для определения местоположения скрипта, который необходимо выполнять. Насмешка и внедрение WordPress выходит за рамки этого поста, но мы, вероятно, рассмотрим это в будущем, так как это полезно при тестировании плагинов. А пока я включу простой автозагрузчик, который в основном добавляет все файлы в корень каталога проекта. Полный исходный код будет опубликован позже в этом посте.
    • цвета. Если вы хотите, чтобы консоль распечатывала отчет о ваших тестах и ​​делала это с использованием цветов (чтобы было легче идентифицировать предупреждения, уведомления, ошибки и т. д.), установите для этого параметра значение true.
    • Ниже приведены все логические значения. Я рекомендую установить для них значение true для наиболее агрессивных возможных отчетов. Таким образом, вам не удастся просто пропустить уведомления или предупреждения, беспокоясь только об ошибках. Это скорее упражнение в качестве кода, чем что-либо еще.
      • конвертеррорстоексцептионс
      • конвертироватьNoticesToExceptions
      • конвертироватьWarningsToExceptions
  • наборы тестов состоят из наборов тестов. Поскольку данный проект может иметь несколько тестов, важно убедиться, что вы даете каждому набору уникальное имя и указываете правильный путь к группе тестов. В нашем примере у нас будет только один набор тестов, и он будет находиться в каталоге с тестами .
  • ведение журнала — это функция, которая может быть такой же простой, как вывод данных в консоль или использование сторонней библиотеки (например, Clover) для создания отчетов, которые помогают с непрерывной интеграцией. Поскольку я еще не обсуждал последнее в одном из своих предыдущих постов, мы собираемся придерживаться консоли в качестве основного метода вывода. Таким образом, у нас есть php ://stdout как наш единственный вывод журнала.

С учетом всего сказанного наш файл XML содержит все, что нужно PHPUnit для работы без каких-либо других параметров.

Помните, однако, что прежде чем продолжить эту статью, я предполагаю, что вы глобально установили PHPUnit в своей системе с помощью Composer. Если нет, просмотрите эту статью, так как она предоставит вам инструкции о том, как это сделать.

После этого вы можете убедиться, что PHPUnit установлен, введя следующую команду в своем терминале:

$ which phpunit

И вы должны увидеть что-то вроде следующего:

Если вы видите что-то вроде вышеприведенного, то вы можете запустить PHPUnit из любой точки вашей системы.

3 Загрузочный файл

Прежде чем идти дальше, давайте напишем базовый файл начальной загрузки. Мы назовем его bootstrap.php и поместим в каталог с тестами . Он будет включать следующее:

<?php
// This array has a single file but could whole the contents of an entire directory.
$files = [
    dirname(__DIR__).'/AcmeCache.php',
];

foreach ($files as $file) {
    if (file_exists($file)) {
        require_once $file;
    }
}

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

На этом этапе давайте настроим базовый тест.

4 Базовый, провальный тест

Если вы читали что-нибудь о разработке через тестирование, то наверняка слышали о цикле «красный-зеленый-повтор». Об этом можно много говорить, и я рекомендую прочитать об этом, но это не цель этого поста.

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

  1. создайте каталог, в котором у вас будут базовые файлы PHP, которые мы будем тестировать,
  2. в корне каталога также создайте phpunit.xml и заполните его, используя код, опубликованный ранее в этом посте.
  3. создайте каталог с тестами, в котором мы будем размещать наши тесты.

Теперь из терминала перейдите в каталог проекта (которого пока нет), а затем просто запустите php unit:

$ phpunit

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

Написание модульных тестов с помощью PHPUnit, часть 3: конфигурация XML

Поскольку у нас нет ни кода, ни тестов, мы, естественно, увидим вывод выше, верно? Итак, давайте напишем один тест, который будет выполняться (и терпеть неудачу), поскольку для него нет кода, который можно было бы протестировать.

Во-первых, в каталоге тестов создайте файл с именем AcmeCacheTest.php. И давайте сделаем что-нибудь простое, например, создадим экземпляр объекта кеша, который мы в конечном итоге создадим.

<?php

namespace AcmeTests;

use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;

class AcmeCacheTest extends TestCase
{
    private $cache;

    public function setUp()
    {
        $this->cache = new AcmeCache();
    }

    public function testCacheExists()
    {
        $this->assertNotNull($this->cache);
    }
}

Перед запуском теста обратите внимание, что мы:

  1. Обязательно используйте PHPUnitFrameworkTestCase.
  2. И пусть наш класс расширяет TestCase

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

$ phpunit

После этого вы должны увидеть следующее:

Написание модульных тестов с помощью PHPUnit, часть 3: конфигурация XML

Обратите внимание, что это приведет к неудачному тесту и сообщит вам, где была обнаружена проблема, файл и строка.

Чтобы исправить это, нам нужно написать класс:

<?php

namespace Acme;

class AcmeCache
{
    private $duration;

    public function __construct()
    {
        $this->duration = 43200;
    }

    public function setDuration(int $duration)
    {
        $this->duration = $duration;
    }

    public function getDuration(): int
    {
        return $this->duration;
    }
}

4 Несколько основных, прохождение тестов

Базовый проходной тест (который будет основан на предыдущем коде) будет включать следующее:

  • файл с пространством имен,
  • будет представлять собой простой кеш,
  • будет автоматически загружен PHPUnit с использованием файла bootstrap.php, опубликованного выше
  • и будет иметь продолжительность, установленную в его конструкторе вместе с сеттером и геттером для значения

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

<?php

namespace AcmeTests;

use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;

class AcmeCacheTest extends TestCase
{
    private $cache;

    public function setUp()
    {
        $this->cache = new AcmeCache();
    }

    public function testCacheExists()
    {
        $this->assertNotNull($this->cache);
    }
}

И запустите тест:

Написание модульных тестов с помощью PHPUnit, часть 3: конфигурация XML

Затем давайте проверим, что установлено значение по умолчанию для кеша:

<?php

namespace AcmeTests;

use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;

class AcmeCacheTest extends TestCase
{
    private $cache;

    public function setUp()
    {
        $this->cache = new AcmeCache();
    }

    public function testCacheExists()
    {
        $this->assertNotNull($this->cache);
    }

    public function testDefaultCacheValue()
    {
        $this->assertSame(43200, $this->cache->getDuration());
    }
}

Как и в предыдущем шаге, запустите тесты, и теперь вы должны увидеть два пройденных теста:

Написание модульных тестов с помощью PHPUnit, часть 3: конфигурация XML

Наконец, давайте проверим, сможем ли мы успешно изменить значение:

<?php

namespace AcmeTests;

use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;

class AcmeCacheTest extends TestCase
{
    private $cache;

    public function setUp()
    {
        $this->cache = new AcmeCache();
    }

    public function testCacheExists()
    {
        $this->assertNotNull($this->cache);
    }

    public function testDefaultCacheValue()
    {
        $this->assertSame(43200, $this->cache->getDuration());
    }

    public function testSetCustomDuration()
    {
        $duration = 4200;

        $this->cache->setDuration($duration);
        $this->assertSame($duration, $this->cache->getDuration());
    }
}

И последние три проходных испытания:

Написание модульных тестов с помощью PHPUnit, часть 3: конфигурация XML

И вот оно:

  1. XML-файл PHPUnit,
  2. простой бутстрап,
  3. один класс с пространством имен,
  4. модульные тесты для каждого метода класса

Конечно, это просто, но это закладывает основы для гораздо большего, чем то, что многие люди уже делают со своими тестами.

Кроме того, это дает вам что-то, на что можно опираться, когда ваши тестовые отбивные становятся сильнее.

Есть ли еще? (Всегда прав?)

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

Обратите внимание, однако, что все, что описано выше, предназначено для того, чтобы начать работу с настройкой собственного XML-файла конфигурации PHPUnit.

Источник записи: tommcfarlin.com

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