Дата обновления перевода 2021-06-12

Тестирование

Как только вы пишете новую строку кода, вы также потенциально добавляете новые ошибки. Для того чтобы создавать более надёжные приложения, вы должны тестировать их, используя как функциональные, так и модульные (unit) тесты.

Тестовый фреймворк PHPUnit

В Symfony интегрирована независимая библиотека под названием PHPUnit, которая предоставляет вам богатый тестовый фреймворк. Эта статья не покрывает все нюансы PHPUnit, но у него есть своя подробная документация.

До создания вашего первого теста, установите phpunit/phpunit и symfony/test-pack, который устанавливает некоторые другие пакеты, предоставляющие полезные тестовые утилиты Symfony:

1
$ composer require --dev phpunit/phpunit symfony/test-pack

После установки библиотеки, попробуйте запустить PHPUnit:

1
$ php ./vendor/bin/phpunit

Эти команды автоматически запускают тесты вашего приложения. Каждый тест - это PHP-класс, заканчивающийся на “Test” (например, BlogControllerTest), который живет в каталоге tests/ вашего приложения.

PHPUnit конфигурируется файлом phpunit.xml.dist в корне вашего приложения. Конфигурации по умолчанию предоставленной Symfony Flex будет достаточно в большинстве случаев. Прочтите `документацию PHPUnit`_, чтобы узнать все возможные опции конфигурации (например, подключение покрытия кода или разделение тестов на множество “наборов тестов”).

Note

Symfony Flex автоматически создает phpunit.xml.dist и tests/bootstrap.php. Если этих файлов нет, вы можете попробовать запустить рецепт, используя composer recipes:install phpunit/phpunit --force -v.

Типы тестов

Существует много типов автоматизированных тестов и точные определения часто разнятся от проекта к проекту. В Symfony используются следующие определения. Если вы учили что-то другое, это не обязательно неправильно, просто отличается от документации, используемой Symfony.

Модульные тесты
Эти тесты гарантируют, что отдельные модули исходного кода (например, один класс) ведут себя, как должны.
Тесты интеграции
Эти тесты тестируют комбинацию классов и часто взаимодействуют с сервис- контейнером Symfony. Эти тесты еще не покрывают полностью работающее приложение, те тесты называются тесты приложения.
Тесты приложения
Тесты приложения тестируют поведение полного приложения. Они делают HTTP- запросы (и реальные и фиктивные) и тестируют, чтобы ответ был ожидаемым.

Модульные тесты

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

По соглашению, каталог tests/ должен быть репликой каталога вашего приложения для модульных тестов. Поэтому, если вы тестируете класс в каталоге src/Form/, поместите тест в каталог tests/Form/. Автозагрузка включается автоматически через файл vendor/autoload.php (как сконфигурировано по умолчанию файлом phpunit.xml.dist).

Вы можете запускать тесты используя команду ./vendor/bin/phpunit:

1
2
3
4
5
6
7
8
# запустить все тесты приложения
$ php ./vendor/bin/phpunit

# запустить все тесты в каталоге Form/
$ php ./vendor/bin/phpunit tests/Form

# запустить тесты для класса UserType
$ php ./vendor/bin/phpunit tests/Form/UserTypeTest.php

Tip

В больших наборах тестов имеет смысл создавать подкаталоги для всех типов тестов (например, tests/Unit/ и test/Functional/).

Тесты интеграции

Тест интеграции будет тестировать большую часть вашего приложения по сравнению с модульным тестом (например, комбинацию сервисов). Тесты интеграции могут хотеть использовать ядро Symfony для извлечения сервиса из контейнера внедрения зависимости.

Symfony предоставляет класс KernelTestCase чтобы помочь вам в создании и запуске ядра в ваших тестах используя bootKernel():

// tests/Service/NewsletterGeneratorTest.php
namespace App\Tests\Service;

use Symfony\Bundle\FrameworkBundle\Test\KernelTestCase;

class NewsletterGeneratorTest extends KernelTestCase
{
    public function testSomething()
    {
        self::bootKernel();

        // ...
    }
}

KernelTestCase также убеждается, что ваше ядро перезапускается для каждого теста. Это гарантирует, что каждый тест выполняется независимо от других.

Чтобы запустить тесты вашего приложения, классу KernelTestCase нужно найти ядро приложения для инициализации. Класс ядра обычно определяется в переменной окружения KERNEL_CLASS (включен в файл по умолчанию .env.test, предоставленный Symfony Flex):

1
2
# .env.test
KERNEL_CLASS=App\Kernel

Note

Если ваш пример использования более сложный, вы также можете переопределить методы getKernelClass() или createKernel() вашего функционального теста, который превосходит переменную окружения KERNEL_CLASS.

Установите окружение вашего теста

Тесты создают ядро, которое работает в окружении test. Это позволяет иметь специальные настройки для ваших тестов внутри config/packages/test/.

Если у вас установлен Symfony Flex, некоторые пакеты уже установили какую-то полезную конфигурацию тестов. Например, по умолчанию, пакет Twig сконфигурирован так, чтобы быть особенно строгим в отлавливании ошибок до развертывания вашего кода в производство:

  • YAML
    1
    2
    3
    # config/packages/test/twig.yaml
    twig:
        strict_variables: true
    
  • XML
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    <!-- config/packages/test/twig.xml -->
    <?xml version="1.0" encoding="UTF-8" ?>
    <container xmlns="http://symfony.com/schema/dic/services"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:twig="http://symfony.com/schema/dic/twig"
        xsi:schemaLocation="http://symfony.com/schema/dic/services
            https://symfony.com/schema/dic/services/services-1.0.xsd
            http://symfony.com/schema/dic/twig
            https://symfony.com/schema/dic/twig/twig-1.0.xsd">
    
        <framework:config strict-variables="true"/>
    </container>
    
  • PHP
    1
    2
    3
    4
    5
    6
    // config/packages/test/twig.php
    use Symfony\Config\TwigConfig;
    
    return static function (TwigConfig $twig) {
        $twig->strictVariables(true);
    };
    

Вы также можете использовать полностью другое окружение, или переоепределить режим отладки по умолчанию (true), передав каждый как опции метода bootKernel():

self::bootKernel([
    'environment' => 'my_test_env',
    'debug'       => false,
]);

Tip

Рекомендуется запускать ваш тест с настройкой debug как false на вашем сервере CI, так как это значительно улучшает производительность теста. Если ваши тесты не работают в чистом окружении каждый раз, вам нужно вручную очстить его, используя экземпляр этого кода в tests/bootstrap.php:

// ...

// гарантировать свежий кеш при отключении режима отладки
(new \Symfony\Component\Filesystem\Filesystem())->remove(__DIR__.'/../var/cache/test');

Настройка переменных окружения

Если вам нужно настроить некоторые переменные окружения для ваших тестов (например, DATABASE_URL, используемый Doctrine), вы можете сделать это переопределив все, что вам нужно, в файле .env.test:

1
2
3
4
# .env.test

# ...
DATABASE_URL="mysql://db_user:[email protected]:3306/db_name_test?serverVersion=5.7"

В окружении тестирования, эти файлы окружения читаются (если переменные в них дублированы, файлы ниже по списку переопределяют предыдущие объекты):

  1. .env: содержащий переменные окружения с значениями приложения по умолчанию;
  2. .env.test: переопределение/установка конкретных значений или переменных теста;
  3. .env.test.local: переопределение настроек конкретно этой машины.

Caution

Файл .env.local не используется в окружении тестирования, чтобы гарантировать, что каждый тест установлен настолько согласовано, насколько это возможно.

Извлечение сервисов в тесте

В ваших тестах интеграции вам часто может быть нужно извлечь сервис из сервис-контейнера, чтобы вызвать какой-то метод. После запуска ядра, контейнер хранится в self::$container:

// tests/Service/NewsletterGeneratorTest.php
namespace App\Tests\Service;

use App\Service\NewsletterGenerator;
use Symfony\Bundle\FrameworkBundle\Test\KernelTestCase;

class NewsletterGeneratorTest extends KernelTestCase
{
    public function testSomething()
    {
        // (1) запустить ядро Symfony
        self::bootKernel();

        // (2) использовать self::$container, чтобы получить доступ к сервис-контейнеру
        $container = self::$container;

        // (3) запустить какие-то сервисы и протестировать результат
        $newsletterGenerator = $container->get(NewsletterGenerator::class);
        $newsletter = $newsletterGenerator->generateMonthlyNews(...);

        $this->assertEquals(..., $newsletter->getContent());
    }
}

Контейнер в self::$container на самом деле - специальный контейнер тестов. Он дает вам доступ как в публичным сервисам, так и к неудаленным частным сервисам.

Note

Если вам нужно протестировать частные сервисы, которые были удалены (те, которые не используются никакими другими сервисами), вам нужно объявить эти частные сервисы публичными в файле config/services_test.yaml.

Конфигурация базы данных для тестов

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

Чтобы сделать так, отредактируйте или создайте файл .env.test.local в корневом каталоге вашего проекта и определите новое значение для переменной окружения DATABASE_URL:

1
2
# .env.test.local
DATABASE_URL="mysql://USERNAME:[email protected]:3306/DB_NAME?serverVersion=5.7"

Предполагается, что каждый разработчик/машина использует разные базы данных для тестов. Если настройка теста одинакова на всех машинах, вместо этого используйте файл .env.test и отправьте его в общее хранилище. Узнайте больше об использовании нескольких файлов .env в приложениях Symfony.

После этого вы можете создать базу данных тестов и все таблицы, используя:

1
2
3
4
5
# создайте базу данных тестов
$ php bin/console --env=test doctrine:database:create

# создайте таблицы/столбцы в базе данных тестов
$ php bin/console --env=test doctrine:schema:create

Tip

Распространенной практикой является добавление суффикса _test к изначальным названиям баз данных в тестах. Если имя базы данных в производстве - project_acme, то имя базы данных тестирования может быть project_acme_test.

Автоматический сброс базы данных перед каждым тестом

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

DAMADoctrineTestBundle использует транзакции Doctrine, чтобы позволить каждому тесту взаимодействовать с неизмененной базой данных. Установите его используя:

1
$ composer require --dev dama/doctrine-test-bundle

Теперь, включите его как расширание PHPUnit:

1
2
3
4
5
6
7
8
<!-- phpunit.xml.dist -->
<phpunit>
    <!-- ... -->

    <extensions>
        <extension class="DAMA\DoctrineTestBundle\PHPUnit\PHPUnitExtension"/>
    </extensions>
</phpunit>

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

Загрузка фикстур фиктивных данных

Вместо использования реальных данных из базы данных производства, в базе данных тестов часто используются ложные или фиктивные данные. Это обычно называется “фикстурными данными” и Doctrine предоставляет библиотеку дла их загрузки и создания. Установите ее:

1
$ composer require --dev doctrine/doctrine-fixtures-bundle

Затем, используйте команду make:fixtures пакета SymfonyMakerBundle, чтобы сгенерирувать пустой класс фикстуры:

1
2
3
4
$ php bin/console make:fixtures

Имя класса фикстур для создания (например, AppFixtures):
> ProductFixture

Затем вы изменяете этот класс, чтобы загружать новые сущности в базу данных. Например, чтобы загрузить объекты Product в Doctrine, используйте:

// src/DataFixtures/ProductFixture.php
namespace App\DataFixtures;

use App\Entity\Product;
use Doctrine\Bundle\FixturesBundle\Fixture;
use Doctrine\Persistence\ObjectManager;

class ProductFixture extends Fixture
{
    public function load(ObjectManager $manager)
    {
        $product = new Product();
        $product->setName('Priceless widget');
        $product->setPrice(14.50);
        $product->setDescription('Ok, I guess it *does* have a price');
        $manager->persist($product);

        // добавить больше продуктов

        $manager->flush();
    }
}

Очистите базу данных и перезагрузите все классы фикстур с помощью:

1
$ php bin/console doctrine:fixtures:load

Чтобы узнать больше, прочтите `документацию DoctrineFixturesBundle`_.

Тесты приложения

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

  1. Сделать запрос;
  2. Взаимодействовать со страницей (например, нажать на ссылку или отправить форму);
  3. Протестировать ответ;
  4. Повторить.

Note

Инструменты, используемые в этом разделе, могут быть установлены через symfony/test-pack, используйте composer require symfony/test-pack, если вы этого еще не сделали.

Напишите свой первый тест приложения

Тесты приложения - это PHP-файлы, которые обычно живут в каталоге вашего проекта tests/Controller/. Они часто расширяют WebTestCase. Этот класс добавляет специальную логику поверх KernelTestCase. Вы можете прочитать больше об этом выше, в разделе о тестах интеграции.

Если вы хотите протестировать страницы, с которыми работает вам класс PostController, начните с создания нового PostControllerTest, используя команду make:test пакета SymfonyMakerBundle:

1
2
3
4
5
6
7
$ php bin/console make:test

 Какой тип теста вы хотите?:
 > WebTestCase

 Имя класса теста (например, BlogPostTest):
 > Controller\PostControllerTest

Это создает следующий класс теста:

// tests/Controller/PostControllerTest.php
namespace App\Tests\Controller;

use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;

class PostControllerTest extends WebTestCase
{
    public function testSomething(): void
    {
        // ВызываетKernelTestCase::bootKernel(), и создает
        // "клиента", действующего как браузер
        $client = static::createClient();

        // Запросить конкретную страницу
        $crawler = $client->request('GET', '/');

        // Валидировать успешный ответ и какое-то содержание
        $this->assertResponseIsSuccessful();
        $this->assertSelectorTextContains('h1', 'Hello World');
    }
}

В примере выше, тест валидирует, что HTTP-ответ был успешен, и что тело запроса содержит тег <h1> с "Hello world".

Метод request() также возвращает краулер, который вы можете использовать, чтобы создать более сложные утверждения в ваших тестах:

$crawler = $client->request('GET', '/post/hello-world');

// например, посчитать количество элементов ``.comment`` на странице
$this->assertCount(4, $crawler->filter('.comment'));

Вы можете узнать больше о краулере в The DOM Crawler.

Создание запросов

Тестовый клиент симулирует HTTP-клиента как браузер и делает запросы в ваше приложение Symfony:

$crawler = $client->request('GET', '/post/hello-world');

Метод request() берет HTTP-метод и URL в качестве аргументов и возвращает экземпляр Crawler.

Tip

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

Полная подпись метода request() следующая:

request(
    $method,
    $uri,
    array $parameters = [],
    array $files = [],
    array $server = [],
    $content = null,
    $changeHistory = true
)

Это позволяет вам создавать все мыслимые типы запросов:

Tip

Тестовый клиент доступен как сервис test.client в контейнере в окружении test (или там, где включена опция framework.test). Это означает, что вы можете переопределить сервис полностью, если вам это понадобится.

Просмотр сайта

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

$client->back();
$client->forward();
$client->reload();

// очищает все куки и историю
$client->restart();

Note

Методы back() и forward() пропускают перенаправления, которые могли возникнуть при запросе URL, как делают это обычные браузеры.

Перенаправление

Когда запрос возвращает ответ перенаправления, клиент не следует ему автоматически. Вы можете исследовать ответ и форсировать перенаправление после этого методом followRedirect():

$crawler = $client->followRedirect();

Если вы хотите, чтобы клиент автоматически следовал всем перенаправлениям, вы можете форсировать их, вызвав метод followRedirects() до выполнения запроса:

$client->followRedirects();

Если вы передадите false методу followRedirects(), перенаправления больше учитываться не будут:

$client->followRedirects(false);

Вход пользователей в систему (аутентификация)

New in version 5.1: Метод loginUser() был представлен в Symfony 5.1.

Когда вы хотите добавить тесты приложения к защищенной странице, вам нужно для начала выполнить “вход” в качестве пользователя. Выполнение необходимых шагов - таких как отправка формы входа в систему - делает тест очень медленным. По этой причине, Symfony предоставляет метод loginUser(), чтобы симулировать вход в систему в ваших функциональных тестах.

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

После загрузки пользователей в вашу базу данных, используйте хранилище пользователей, чтобы извлечь этого пользователя и используйте $client->loginUser(), чтобы сымитириовать запрос входа в систему:

// tests/Controller/ProfileControllerTest.php
namespace App\Tests\Controller;

use App\Repository\UserRepository;
use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;

class ProfileControllerTest extends WebTestCase
{
    // ...

    public function testVisitingWhileLoggedIn()
    {
        $client = static::createClient();
        $userRepository = static::$container->get(UserRepository::class);

        // извлечь тестового пользователя
        $testUser = $userRepository->findOneByEmail('[email protected]');

        // симулировать вход $testUser в систему
        $client->loginUser($testUser);

        // тестировать, например, страницу профиля
        $client->request('GET', '/profile');
        $this->assertResponseIsSuccessful();
        $this->assertSelectorTextContains('h1', 'Hello John!');
    }
}

Вы можете передать любой экземпляр UserInterface методу loginUser(). Этот метод создает специальный объект TestBrowserToken и хранит его в сессии тестового клиента.

Выполнение AJAX-запросов

Клиент предоставляет метод xmlHttpRequest(), который имеет те же аргументы, что и метод request() и является сокращением, чтобы делать AJAX-запросы:

// требуемый заголовок HTTP_X_REQUESTED_WITH добавляется автоматически
$client->xmlHttpRequest('POST', '/submit', ['name' => 'Fabien']);

Отправка пользовательских заголовков

Если ваше поведение ведет себя в соответствии с некоторыми HTTP-заголовками, передайте их в качестве второго аргумента createClient():

$client = static::createClient([], [
    'HTTP_HOST'       => 'en.example.com',
    'HTTP_USER_AGENT' => 'MySuperBrowser/1.0',
]);

Вы также можете переопределить HTTP-заголовки для каждого запроса:

$client->request('GET', '/', [], [], [
    'HTTP_HOST'       => 'en.example.com',
    'HTTP_USER_AGENT' => 'MySuperBrowser/1.0',
]);

Caution

Имя ваших пользовательских заголовком должно следовать синтаксису, определенному в `разделе 4.1.18 в RFC 3875`_: замените - на _, преобразуйте его в заглавные буквы и добавьте к результату префикс HTTP_. К примеру, если имя вашего заголовка - X-Session-Token, передайте HTTP_X_SESSION_TOKEN.

Отчет об исключениях

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

$client->catchExceptions(false);

Доступ к внутренним объектам

Если вы используете клиента, чтобы тестировать ваше приложение, вы можете захотеть получить доступ ко мнутренним объектам клиента:

$history = $client->getHistory();
$cookieJar = $client->getCookieJar();

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

// экземпляр запроса HttpKernel
$request = $client->getRequest();

// экземпляр запроса BrowserKit
$request = $client->getInternalRequest();

// экземпляр ответа HttpKernel
$response = $client->getResponse();

// экземпляр ответа BrowserKit
$response = $client->getInternalResponse();

// экземпляр Crawler
$crawler = $client->getCrawler();

Доступ к данным профилировщика

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

Чтобы получить профилировщика для последнего запроса, сделайте следующее:

// включает профилировщика для всех следующих запросов
$client->enableProfiler();

$crawler = $client->request('GET', '/profiler');

// получает профиль
$profile = $client->getProfile();

Чтобы узнать особые детали использования профилироващика внутри теста, см. статью How to Use the Profiler in a Functional Test.

Взаимодействие с ответом

Как и реальный браузер, объекты Клиента и Карулера могут быть использованы для взаимодействия со страницей, которую вам выдают:

Отправка форм

Используйте метод submitForm(), чтобы отправить форму, содержащую данную кнопку:

$client = static::createClient();
$client->request('GET', '/post/hello-world');

$crawler = $client->submitForm('Add comment', [
    'comment_form[content]' => '...',
]);

Первый аргумент submitForm() - текстовое содержание, id, value или name любого <button> или <input type="submit">, добавленного в форму. Второй необязательный аргумент испоьзуется для переопределения значений полей формы по умолчанию.

Note

Заметьте, что вы должны выбрать кнопки формы, а не формы, так как форма может иметь несколько кнопок. Если вы используете травесирующий API, помните, что вы должны искать кнопку.

Если вам нужно получить доступ к объекту Form, который предоставляет полезные методы специально для форм (такие как getUri(), getValues() и getFields()), используйте вместо этого метод Crawler::selectButton():

$client = static::createClient();
$crawler = $client->request('GET', '/post/hello-world');

// выбрать кнопку
$buttonCrawlerNode = $crawler->selectButton('submit');

// извлечь объект Формы для формы, принадлежашей этой кнопке
$form = $buttonCrawlerNode->form();

// установить значения в объекте формы
$form['my_form[name]'] = 'Fabien';
$form['my_form[subject]'] = 'Symfony rocks!';

// отправить объект Формы
$client->submit($form);

// по желанию, вы можете объединить 2 последних шага, передав массив значений
// поля при отправке формы:
$client->submit($form, [
    'my_form[name]'    => 'Fabien',
    'my_form[subject]' => 'Symfony rocks!',
]);

В зависимости от типа формы, вы можете использовать разные методы, чтобы заполнить ввод:

// выбирает опцию или радио-кнопку
$form['my_form[country]']->select('France');

// отмечает чекбокс
$form['my_form[like_symfony]']->tick();

// загружает файл
$form['my_form[photo]']->upload('/path/to/lucas.jpg');

// В случае загрузки нескольких файлов
$form['my_form[field][0]']->upload('/path/to/lucas.jpg');
$form['my_form[field][1]']->upload('/path/to/lisa.jpg');

Tip

Вместо жесткого кодирования имени формы как части имен полей (например, my_form[...] в предыдущем примере), вы можете использовать метод getName(), чтобы получить имя формы.

Tip

Если вы специально хотите выбрать значения кнопок радио/выбора “invalid”, см. Selecting Invalid Choice Values.

Tip

Вы можете получить значения, которые будут отправлены путем вызова метода getValues() в объекте Form. Загруженные файлы доступны в отдельном массиве, возвращенном getFiles(). Методы getPhpValues() и getPhpFiles() также возвращают отправленные данные, но в PHP-формате (он конвертирует ключи с нотацией квадратными скобками - например, my_form[subject] - в PHP-массивы).

Tip

Методы submit() м submitForm() определяют необязательные аргументы для добавления пользовательских параметров сервиса и HTTP-заголовков при отправке формы:

$client->submit($form, [], ['HTTP_ACCEPT_LANGUAGE' => 'es']);
$client->submitForm($button, [], 'POST', ['HTTP_ACCEPT_LANGUAGE' => 'es']);

Тестирование ответов (утверждения)

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

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

Однако, Symfony предоставляет удобные методы сокращений для большинства распространенных случаев:

Утверждения ответов

assertResponseIsSuccessful(string $message = '')
Утверждает, что ответ был успешен (HTTP-статус 2xx).
assertResponseStatusCodeSame(int $expectedCode, string $message = '')
Утверждает конкретный HTTP статус-код.
assertResponseRedirects(string $expectedLocation = null, int $expectedCode = null, string $message = '')
Утверждает, что ответ - это ответ перенаправления (по желанию, вы можете проверить целевую локацию и статус-код).
assertResponseHasHeader(string $headerName, string $message = '')/assertResponseNotHasHeader(string $headerName, string $message = '')
Утверждает, что заданный заголовок - (не) доступен в ответе.
assertResponseHeaderSame(string $headerName, string $expectedValue, string $message = '')/assertResponseHeaderNotSame(string $headerName, string $expectedValue, string $message = '')
Утверждает, что заданный заголовок (не) содержит ожидаемого значение в ответе.
assertResponseHasCookie(string $name, string $path = '/', string $domain = null, string $message = '')/assertResponseNotHasCookie(string $name, string $path = '/', string $domain = null, string $message = '')
Утверждает, что заданный куки есть в ответе (по желанию, проверяет путь или домен конкретного куки).
assertResponseCookieValueSame(string $name, string $expectedValue, string $path = '/', string $domain = null, string $message = '')
Утверждает, что заданный куки существует и устаналивает ожидаемое значение.
assertResponseFormatSame(?string $expectedFormat, string $message = '')
Утверждает, что формат возвращенного методом getFormat() ответа такой же, как и ожидаемое значение.

New in version 5.3: The assertResponseFormatSame() method was introduced in Symfony 5.3.

Утверждения запросов

assertRequestAttributeValueSame(string $name, string $expectedValue, string $message = '')
Утверждает, что заданный атрибут запроса установлен в ожидаемом значении.
assertRouteSame($expectedRoute, array $parameters = [], string $message = '')
Утверждает ответ, сопосталвенный с заданным маршрутом и, по желанию, параметры маршрута.

Утверждения браузера

assertBrowserHasCookie(string $name, string $path = '/', string $domain = null, string $message = '')/assertBrowserNotHasCookie(string $name, string $path = '/', string $domain = null, string $message = '')
Утверждает, что Клиент теста (не) имеет установленного заданного куки (что означает, что куки был установлен любым запросом в тесте).
assertBrowserCookieValueSame(string $name, string $expectedValue, string $path = '/', string $domain = null, string $message = '')
Утверждает, что заданный куки в тестовом Клиенте установлен в ожидвемом значении.

Утверждения краулеров

assertSelectorExists(string $selector, string $message = '')/assertSelectorNotExists(string $selector, string $message = '')
Утверждает, что заданный cелектор (не) совпадает как минимум с одним элементом в ответе.
assertSelectorTextContains(string $selector, string $text, string $message = '')/assertSelectorTextNotContains(string $selector, string $text, string $message = '')
Утверждает, что первый элемент, совпадающий с заданным селектором (не) содержит ожидаемый текст.
assertSelectorTextSame(string $selector, string $text, string $message = '')
Утверждает, что содержание первого элемента, совпадающего с заданным селектором (не) равняется ожидаемому тексту.
assertPageTitleSame(string $expectedTitle, string $message = '')
Утверждает, что элемент <title> равен заданному заголовку.
assertPageTitleContains(string $expectedTitle, string $message = '')
Утверждает, что элемент <title> содержит заданный заголовок.
assertInputValueSame(string $fieldName, string $expectedValue, string $message = '')/assertInputValueNotSame(string $fieldName, string $expectedValue, string $message = '')
Утверждает, что значение ввода формы с заданным именем (не) равняется ожидаемому значению.
assertCheckboxChecked(string $fieldName, string $message = '')/assertCheckboxNotChecked(string $fieldName, string $message = '')
Утверждает, что чекбокс с заданным именем (не) отмечен.
assertFormValue(string $formSelector, string $fieldName, string $value, string $message = '')/assertNoFormValue(string $formSelector, string $fieldName, string $message = '')
Утверждает, что значение поля первой формы, совпадающей с заданным селектором (не) равняется ожидаемому значению.

New in version 5.2: Методы assertCheckboxChecked(), assertCheckboxNotChecked(), assertFormValue() и assertNoFormValue() были представлены в Symfony 5.2.

Утверждения почтовых программ

New in version 5.1: Начиная с Symfony 5.1, следующие утвепждения больше не требуют запроса с Client в случае теста, расширяющего класс WebTestCase.

assertEmailCount(int $count, string $transport = null, string $message = '')
Утверждает, что было отправлено ожидаемо количество электронных писем.
assertQueuedEmailCount(int $count, string $transport = null, string $message = '')
Утверждает, что ожидаемое количество электронных писем было поставлено в очередь (например, используя компонент Messenger).
assertEmailIsQueued(MessageEvent $event, string $message = '')/assertEmailIsNotQueued(MessageEvent $event, string $message = '')
Утверждает, что заданное событие почтовой программы (не) в очереди. Используйте getMailerEvent(int $index = 0, string $transport = null), чтобы извлечь событие почтовой программы по индексу.
assertEmailAttachmentCount(RawMessage $email, int $count, string $message = '')
Утверждает, что заданное электронное письмо имеет ожидаемое количество вложений. Используйте getMailerMessage(int $index = 0, string $transport = null), чтобы извлечь конкретное письмо по индексу.
assertEmailTextBodyContains(RawMessage $email, string $text, string $message = '')/assertEmailTextBodyNotContains(RawMessage $email, string $text, string $message = '')
Утверждает, что тело текста заданного письма (не) содержит ожидаемый текст.
assertEmailHtmlBodyContains(RawMessage $email, string $text, string $message = '')/assertEmailHtmlBodyNotContains(RawMessage $email, string $text, string $message = '')
Утверждает, что HTML-тело заданного письма (не) содержит ожидаемый текст.
assertEmailHasHeader(RawMessage $email, string $headerName, string $message = '')/assertEmailNotHasHeader(RawMessage $email, string $headerName, string $message = '')
Утверждает, что заданное письмо (не) имеет ожидаемого установленного заголовка.
assertEmailHeaderSame(RawMessage $email, string $headerName, string $expectedValue, string $message = '')/assertEmailHeaderNotSame(RawMessage $email, string $headerName, string $expectedValue, string $message = '')
Утверждает, что заданное письмо (не) имеет ожидаемого заголовка, установленного в ожидаемое значение.
assertEmailAddressContains(RawMessage $email, string $headerName, string $expectedValue, string $message = '')
Утверждает, что заданный заголовок адреса равняется ожидаемому адресу электронной почты. Это утверждение нормализует адреса вроде Jane Smith <jane@example.com> в jane@example.com.

Сквозные тесты (E2E)

  • panther
  • testing javascript
  • UX or form collections as example?

Эта документация является переводом официальной документации Symfony и предоставляется по свободной лицензии CC BY-SA 3.0.