Меню

Как запустить тест laravel



Testing: Getting Started

Introduction

Laravel is built with testing in mind. In fact, support for testing with PHPUnit is included out of the box and a phpunit.xml file is already set up for your application. The framework also ships with convenient helper methods that allow you to expressively test your applications.

By default, your application’s tests directory contains two directories: Feature and Unit . Unit tests are tests that focus on a very small, isolated portion of your code. In fact, most unit tests probably focus on a single method. Tests within your «Unit» test directory do not boot your Laravel application and therefore are unable to access your application’s database or other framework services.

Feature tests may test a larger portion of your code, including how several objects interact with each other or even a full HTTP request to a JSON endpoint. Generally, most of your tests should be feature tests. These types of tests provide the most confidence that your system as a whole is functioning as intended.

An ExampleTest.php file is provided in both the Feature and Unit test directories. After installing a new Laravel application, execute the vendor/bin/phpunit or php artisan test commands to run your tests.

Environment

When running tests, Laravel will automatically set the configuration environment to testing because of the environment variables defined in the phpunit.xml file. Laravel also automatically configures the session and cache to the array driver while testing, meaning no session or cache data will be persisted while testing.

You are free to define other testing environment configuration values as necessary. The testing environment variables may be configured in your application’s phpunit.xml file, but make sure to clear your configuration cache using the config:clear Artisan command before running your tests!

The .env.testing Environment File

In addition, you may create a .env.testing file in the root of your project. This file will be used instead of the .env file when running PHPUnit tests or executing Artisan commands with the —env=testing option.

The CreatesApplication Trait

Laravel includes a CreatesApplication trait that is applied to your application’s base TestCase class. This trait contains a createApplication method that bootstraps the Laravel application before running your tests. It’s important that you leave this trait at its original location as some features, such as Laravel’s parallel testing feature, depend on it.

Creating Tests

To create a new test case, use the make:test Artisan command. By default, tests will be placed in the tests/Feature directory:

If you would like to create a test within the tests/Unit directory, you may use the —unit option when executing the make:test command:

Once the test has been generated, you may define test methods as you normally would using PHPUnit. To run your tests, execute the vendor/bin/phpunit or php artisan test command from your terminal:

If you define your own setUp / tearDown methods within a test class, be sure to call the respective parent::setUp() / parent::tearDown() methods on the parent class.

Running Tests

As mentioned previously, once you’ve written tests, you may run them using phpunit :

In addition to the phpunit command, you may use the test Artisan command to run your tests. The Artisan test runner provides verbose test reports in order to ease development and debugging:

Any arguments that can be passed to the phpunit command may also be passed to the Artisan test command:

Running Tests In Parallel

By default, Laravel and PHPUnit execute your tests sequentially within a single process. However, you may greatly reduce the amount of time it takes to run your tests by running tests simultaneously across multiple processes. To get started, ensure your application depends on version ^5.3 or greater of the nunomaduro/collision package. Then, include the —parallel option when executing the test Artisan command:

By default, Laravel will create as many processes as there are available CPU cores on your machine. However, you may adjust the number of processes using the —processes option:

When running tests in parallel, some PHPUnit options (such as —do-not-cache-result ) may not be available.

Parallel Testing & Databases

Laravel automatically handles creating and migrating a test database for each parallel process that is running your tests. The test databases will be suffixed with a process token which is unique per process. For example, if you have two parallel test processes, Laravel will create and use your_db_test_1 and your_db_test_2 test databases.

By default, test databases persist between calls to the test Artisan command so that they can be used again by subsequent test invocations. However, you may re-create them using the —recreate-databases option:

Parallel Testing Hooks

Occasionally, you may need to prepare certain resources used by your application’s tests so they may be safely used by multiple test processes.

Using the ParallelTesting facade, you may specify code to be executed on the setUp and tearDown of a process or test case. The given closures receive the $token and $testCase variables that contain the process token and the current test case, respectively:

Accessing The Parallel Testing Token

If you would like to access to current parallel process «token» from any other location in your application’s test code, you may use the token method. This token is a unique, integer identifier for an individual test process and may be used to segment resources across parallel test processes. For example, Laravel automatically appends this token to the end of the test databases created by each parallel testing process:

Источник

Laravel Framework Russian Community

Пролог

  • Примечания к релизу
  • Руководство по обновлению
  • Рекомендации по участию
  • Начало работы

    • Установка
    • Конфигурация
    • Структура каталогов
    • Стартовые наборы
    • Развертывание
  • Архитектурные концепции

    • Жизненный цикл запроса
    • Сервис-контейнер
    • Сервис-провайдеры
    • Фасады
  • Основное

    • Маршрутизация
    • Посредники
    • CSRF Защита
    • Контроллеры
    • HTTP-запросы
    • HTTP-ответы
    • Представления
    • Шаблоны Blade
    • Генерация URL
    • Сессии
    • Валидация
    • Обработка ошибок
    • Логирование
  • Погружение

    • Artisan консоль
    • Широковещание
    • Кэширование
    • Коллекции
    • Компиляция JS и CSS
    • Контракты
    • События
    • Файловое хранилище
    • Помощники
    • HTTP Клиент
    • Локализация
    • Почта
    • Уведомления
    • Разработка пакетов
    • Очереди
    • Планировщик
  • Безопасность

    • Аутентификация
    • Авторизация
    • Верификация email
    • Шифрование
    • Хеширование
    • Сброс пароля
  • База данных

    • Начало работы
    • Конструктор запросов
    • Пагинация
    • Миграции
    • Загрузка начальных данных
    • Redis
  • Eloquent ORM

    • Начало работы
    • Отношения
    • Коллекции
    • Мутаторы / Типизация
    • API Ресурсы
    • Сериализация
  • Тестирование

    • Начало работы
    • HTTP Тесты
    • Консольные Тесты
    • Браузерные Тесты
    • База данных
    • Имитация
  • Пакеты

    • Breeze
    • Cashier (Stripe)
    • Cashier (Paddle)
    • Dusk
    • Envoy
    • Fortify
    • Homestead
    • Horizon
    • Jetstream
    • Passport
    • Sail
    • Sanctum
    • Scout
    • Socialite
    • Telescope
    • Valet
    • API Документация
  • Тестирование · Начало работы

    • Введение
    • Окружение
    • Создание тестов
    • Запуск тестов
      • Параллельное выполнение тестов

    Введение

    Laravel построен с учетом требований тестирования. Фактически, поддержка тестирования с помощью PHPUnit включена прямо из коробки, и файл phpunit.xml уже настроен для вашего приложения. Фреймворк также поставляется с удобными вспомогательными методами, позволяющими выразительно тестировать ваши приложения.

    По умолчанию каталог tests вашего приложения содержит два каталога: Feature и Unit . Модульные (юнит) тесты – это тесты, которые фокусируются на очень небольшой изолированной части вашего кода. Фактически, большинство модульных тестов, вероятно, сосредоточены на одном методе. Тесты в каталоге «Unit» тестов не загружают ваше приложение Laravel и, следовательно, не могут получить доступ к базе данных вашего приложения или другим службам фреймворка.

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

    Файл ExampleTest.php находится в каталогах тестов Feature и Unit . После установки нового приложения Laravel выполните команды vendor/bin/phpunit или php artisan test из командной строки для запуска ваших тестов.

    Окружение

    При запуске тестов, Laravel автоматически устанавливает конфигурацию окружения как «тестовое» благодаря переменной окружения, определенной в файле phpunit.xml . Laravel во время тестирования также автоматически настраивает для сессии и кеша драйверы array , что означает, что во время тестирования данные сессии или кеша не сохраняются.

    При необходимости вы можете определять другие значения конфигурации среды тестирования. Переменные окружения testing могут быть настроены в файле phpunit.xml , но перед запуском тестов не забудьте очистить кеш конфигурации с помощью команды config:clear Artisan!

    Переменная окружения .env.testing

    Кроме того, вы можете создать файл .env.testing в корне вашего проекта. Этот файл будет использоваться вместо .env при запуске тестов PHPUnit или выполнении команд Artisan с параметром —env=testing .

    Трейт CreatesApplication

    Laravel содержит трейт CreatesApplication , который применяется к базовому классу TestCase вашего приложения. Этот трейт содержит метод createApplication , который загружает приложение Laravel перед запуском ваших тестов. Важно, чтобы вы оставили этот трейт в его исходном месте, так как от него зависит некоторый функционал, например, функционал параллельного тестирования Laravel.

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

    Чтобы сгенерировать новый тест, используйте команду make:test Artisan. Эта команда поместит новый класс теста в каталог tests/Feature вашего приложения:

    Если вы хотите создать тест в каталоге tests/Unit , то используйте параметр —unit при выполнении команды make:test :

    После того, как тест был сгенерирован, вы можете определить методы тестирования, как обычно, используя PHPUnit. Чтобы запустить ваши тесты, выполните команду vendor/bin/phpunit или php artisan test из вашего терминала:

    Запуск тестов

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

    В дополнение к команде phpunit , вы можете использовать команду test Artisan для запуска ваших тестов. Тестер Artisan отображает подробные отчеты о тестах для упрощения разработки и отладки:

    Любые аргументы, которые могут быть переданы команде phpunit , также могут быть переданы команде Artisan test :

    Параллельное выполнение тестов

    По умолчанию Laravel и PHPUnit выполняют ваши тесты последовательно в рамках одного процесса. Однако вы можете значительно сократить время, необходимое для запуска тестов, за счет одновременного выполнения тестов в нескольких процессах. Для начала добавьте параметр —parallel при выполнении команды test Artisan:

    По умолчанию Laravel создает столько процессов, сколько ядер ЦП доступно на вашем компьютере. Однако вы можете настроить количество процессов, используя параметр —processes :

    Параллельное тестирование и базы данных

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

    По умолчанию тестовые базы данных сохраняются между вызовами команды test Artisan, чтобы их можно было использовать снова при последующих вызовах test . Однако вы можете пересоздать их, используя параметр —recreate-databases :

    Хуки параллельного тестирования

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

    Используя фасад ParallelTesting , вы можете указать код, который будет выполняться в setUp и tearDown процесса или тестового класса. Переданные замыкания получат переменные $token и $testCase , которые содержат токен процесса и текущий тестовый класс, соответственно:

    Доступ к токену процесса параллельного тестирования

    Если вы хотите получить доступ к «токену» текущего процесса из любого другого места в коде теста вашего приложения, то вы можете использовать метод token . Этот токен представляет собой уникальный целочисленный идентификатор для каждого из процессов тестирования и может использоваться для разделения подготавливаемых ресурсов процессов параллельного тестирования. Например, Laravel автоматически добавляет этот токен в конец тестовых баз данных, создаваемых каждым процессом параллельного тестирования:

    Источник

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

    Вступление

    Laravel построен с учетом тестирования. На самом деле поддержка тестирования с помощью PHPUnit включена из коробки, и файл уже настроен для вашего приложения. Фреймворк также поставляется с удобными вспомогательными методами, которые позволяют вам выразительно тестировать ваши приложения. phpunit.xml

    По умолчанию tests каталог вашего приложения содержит два каталога: Feature и Unit . Модульные тесты — это тесты, которые фокусируются на очень маленькой изолированной части вашего кода. Фактически, большинство модульных тестов, вероятно, сосредоточены на одном методе. Функциональные тесты могут проверять большую часть вашего кода, включая взаимодействие нескольких объектов друг с другом или даже полный HTTP-запрос к конечной точке JSON.

    Файл предоставляется в обоих и тестовых каталогах. После установки нового приложения Laravel запустите тестирование из командной строки. ExampleTest.php Feature Unit phpunit

    Среда

    При запуске тестов через phpunit Laravel автоматически устанавливает среду конфигурации testing из-за переменных среды, определенных в файле. Laravel также автоматически настраивает сеанс и кэш для драйвера во время тестирования, что означает, что данные сеанса или кеша не будут сохранены во время тестирования. phpunit.xml array

    Вы можете при необходимости определить другие значения конфигурации среды тестирования. В testing переменные окружения могут быть настроены в файле, но убедитесь , чтобы очистить кэш конфигурации с помощью Artisan команду перед запуском тесты! phpunit.xml config:clear

    Кроме того, вы можете создать файл в корне вашего проекта. Этот файл переопределит файл при запуске тестов PHPUnit или выполнении команд Artisan с параметром. .env.testing .env —env=testing

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

    Чтобы создать новый контрольный пример, используйте команду Artisan: make:test

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

    Если вы определяете свои собственные методы setUp / tearDown в тестовом классе, обязательно вызовите соответствующие методы / в родительском классе. parent::setUp() parent::tearDown()

    Источник

    Как писать тесты в Laravel

    Laravel Тесты

    В этом уроке мы расскажем о том, как начать писать функциональные тесты PHPUnit в Laravel.

    Давайте рассмотрим блог-приложение, где есть модель Post и она имеет поля title и body . Давайте напишем функциональный тест в стиле TDD (Test-Driven Development — Разработка через тестирование), чтобы проверить функциональность модели.

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

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

    Для тестов мы должны иметь возможность брать точные данные, которые необходимы для работы конкретного теста.

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

    Значение :memory: переменной DB_DATABASE говорит sqlite, что мы используем не реальные файлы, а работаем в памяти.

    Отлично, теперь мы готовы написать первый функциональный тест.

    Откройте вашу IDE и перейдите в папку tests/Feature .

    Tests Feature

    Обратите внимание, что в папке уже есть файл ExampleTest.php . Здесь мы и создадим новый тест.

    Для этого перейдите в терминал/командную строку и выполните следующую команду.

    В папке tests/Feature появится новый тест под названием PostsTest.php со следующим кодом

    Давайте изменим его и поработаем в стиле TDD.

    Модифицируйте ваш PostsTest как показано ниже.

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

    Мы переименовали нашу функцию в a_user_can_browse_posts и обратите внимание на комментарий /** @test */ в верхней части функции. Это важно, так как по нему phpunit распознает наш тест во время работы.

    Перейдите в терминал и запустите тест, выполнив следующую команду.

    Тест не пройден с ошибкой

    Это было ожидаемо, ведь в файле web.php еще нет маршрута для /posts .

    Давайте его добавим. Перейдите в файл web.php и добавьте следующий маршрут.

    Запустите тест снова и он должен выдать зеленое сообщение

    Пример успешного теста в Laravel

    Все идёт отлично. Давайте теперь изменим этот тест, так как пока он нам только говорит, что страница /posts работает. Нам нужно убедиться, что на этой странице мы также видим сообщения.

    Откройте PostController.php и измените метод index для получения сообщений и передачи их в шаблон.

    Теперь нам нужно создать шаблон index.blade.php в папке resources/views/posts

    Изменим наш тест для проверки того, что мы видим сообщения на странице /posts .

    Запустите тест еще раз, он должен выдать зеленое сообщение. Готово! Мы написали свой первый функциональный тест в Laravel.

    Наш Телеграм-канал — следите за новостями о Laravel.

    Задать вопросы по урокам можно на нашем форуме.

    Источник

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

    Testing → Community Community +1 015 30 июня 2015

    Введение

    Laravel построен с учётом тестирования. Фактически, поддержка PHPUnit доступна по умолчанию, а файл phpunit.xml уже настроен для вашего приложения. Также фреймворк содержит удобные методы для полноценного тестирования ваших приложений.

    Папка tests содержит файл с примером теста ExampleTest.php . После установки нового приложения Laravel просто выполните команду sh phpunit для запуска ваших тестов.

    Среда

    При выполнении тестов Laravel автоматически задаст настройки среды testing . Также при тестировании Laravel автоматически настроит сессии и кэш на драйвер array , а значит данные сессий и кэша не сохранятся при тестировании.

    При необходимости вы можете определить другие значения настроек для тестовой среды. Переменные среды testing можно настроить в файле phpunit.xml , но перед запуском тестов не забудьте очистить кэш настроек с помощью Artisan-команды sh config:clear !

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

    Для создания теста используйте Artisan-команду sh make:test :

    Эта команда поместит новый класс UserTest в папку tests . Далее вы можете объявлять методы тестов как вы обычно объявляете их для PHPUnit. Для запуска тестов просто выполните команду sh phpunit в терминале:

    Если вы определили собственный метод PHP setUp () , не забудьте вызвать PHP parent :: setUp () .

    Начиная с версии Laravel 5.3 последующие разделы данной статьи вынесены в отдельные статьи Тестирование приложения, Тестирование БД и Заглушки. — прим. пер.

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

    Laravel предоставляет очень удобный API для создания HTTP-запросов к вашему приложению, проверки вывода, и даже заполнения форм. Например, посмотрим на файл ExampleTest.php в папке tests :

    Метод PHP visit () делает GET -запрос в приложение. Метод PHP see () объявляет, что мы должны увидеть данный текст в отклике приложения. Метод PHP dontSee () объявляет, что данный текст не возвращается в отклике приложения. Это самый базовый тест приложения в Laravel.

    Взаимодействие с приложением

    Само собой, можно делать намного больше, чем просто проверять появление текста в данном отклике. Давайте рассмотрим несколько примеров нажатия ссылок и заполнения форм.

    Нажатие ссылок

    В этом тесте мы сделаем запрос в приложение, «нажмём» ссылку в возвращённом отклике, а затем проверим, что оказались на нужном URI. Например, предположим, что в нашем отклике есть ссылка с текстом «О нас» :

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

    Работа с формами

    Также Laravel предоставляет несколько методов для тестирования форм. Методы PHP type () , PHP select () , PHP check () , PHP attach () и PHP press () позволяют вам взаимодействовать со всеми элементами ввода на ваших формах. Например, представим, что на странице регистрации в приложении есть такая форма:

    Мы можем написать тест для заполнения этой формы и проверки результата:

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

    Метод Описание
    $this->type($text, $elementName) Ввести текст в данное поле
    $this->select($value, $elementName) Выбрать радио-кнопку или выпадающее поле
    $this->check($elementName) Поставить чекбокс
    $this->uncheck($elementName) Снять чекбокс (для 5.2 и выше)
    $this->attach($pathToFile, $elementName) Прикрепить файл к форме
    $this->press($buttonTextOrElementName) Нажать кнопку с заданным текстом или именем

    Работа с вложениями

    Если на вашей форме есть элементы ввода типа file , вы можете прикрепить файлы к форме методом PHP attach () :

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

    Также Laravel предоставляет несколько вспомогательных функций для тестирования JSON API и их откликов. Например, методы PHP get () , PHP post () , PHP put () , PHP patch () и PHP delete () используются для выполнения различных HTTP-запросов. Вы также легко можете передать данные и заголовки в эти методы. Для начала давайте напишем тест, выполняющий POST -запрос к /user и проверяющий, что данный массив возвращается в формате JSON:

    Метод PHP seeJson () конвертирует данный массив в JSON, а затем проверяет, что фрагмент JSON появляется где-либо внутри полного JSON-отклика, возвращаемого приложением. Поэтому, если в нём будут ещё и другие свойства, этот тест всё равно будет пройден успешно, так как данный фрагмент присутствует в отклике.

    Проверка точного совпадения JSON

    Если вы хотите проверить точное совпадение данного массива с возвращённым из приложения JSON, вам надо использовать метод PHP seeJsonEquals () :

    Проверка структуры JSON

    Также можно проверить соответствие структуры JSON определённым требованиям. Для этого служит используйте метод PHP seeJsonStructure () и передайте в него список (вложенных) ключей:

    В этом примере ожидается получение name и вложенного объекта pet с его собственными name и age . Метод PHP seeJsonStructure () выполнится без ошибки, если в отклике будут дополнительные ключи. Например, проверка будет пройдена и в том случае, когда pet будет иметь атрибут weight .

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

    Вы можете использовать вложение * . Тогда мы потребуем, что каждый user в JSON отклике должен содержать заданный набор атрибутов, и каждый pet каждого user также должен содержать заданный набор атрибутов:

    Сессии / Аутентификация

    В Laravel есть несколько функций для работы с сессиями во время тестирования. Сначала вы можете задать данные сессии для данного массива при помощи метода PHP withSession () . Это полезно для загрузки сессии с данными перед выполнением тестового запроса в приложение:

    Конечно, чаще всего сессии используют для задания нужного состояния пользователя, например, аутентифицированный пользователь. Простой способ аутентифицировать данного пользователя в качестве текущего — метод PHP actingAs () . Например, мы можем использовать фабрику модели, чтобы сгенерировать и аутентифицировать пользователя:

    Вторым аргументом метода PHP actingAs () вы можете указать защитника для аутентификации данного пользователя:

    Отключение посредников

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

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

    Свои HTTP-запросы

    Если вы хотите сделать свой HTTP-запрос в приложение и получить полный объект Illuminate\Http\Response , используйте метод PHP call () :

    Если вы делаете запросы POST , PUT или PATCH , то можете передать массив входных данных вместе с запросом. Тогда эти данные будут доступны в ваших маршрутах и контроллере через экземпляр запроса:

    Проверки PHPUnit (assertions)

    Laravel предоставляет несколько assert-методов для тестов PHPUnit:

    Метод Описание
    ->assertResponseOk(); Проверка того, что клиентский отклик имеет статус ОК
    ->assertResponseStatus($code); Проверка того, что клиентский отклик имеет указанный статус.
    ->assertViewHas($key, $value = null); Проверка того, что представление в отклике содержит данный кусок привязанных данных.
    ->assertViewHasAll(array $bindings); Проверка того, что представление содержит данный список привязанных данных.
    ->assertViewMissing($key); Проверка того, что в представлении в отклике отсутствует данный кусок привязанных данных.
    ->assertRedirectedTo($uri, $with = []); Проверка того, что клиент был переадресован по данному URI
    ->assertRedirectedToRoute($name, $parameters = [], $with = []); Проверка того, что клиент был переадресован по данному маршруту
    ->assertRedirectedToAction($name, $parameters = [], $with = []); Проверка того, что клиент был переадресован к данному действию
    ->assertSessionHas($key, $value = null); Проверка того, что в сессии есть данное значение.
    ->assertSessionHasAll(array $bindings); Проверка того, что в сессии есть данный список значений.
    ->assertSessionHasErrors($bindings = [], $format = null); Проверка того, что в сессии есть привязанные ошибки.
    ->assertHasOldInput(); Проверка того, что в сессии есть введённые ранее данные.
    ->assertSessionMissing($key); Проверка того, что в сессии нет указанного ключа (для версии 5.2 и выше).

    Вызов контроллера из теста

    Вы также можете вызвать из теста любой контроллер:

    Вам не надо указывать полное пространство имён контроллера при использовании метода PHP action () . Укажите только ту часть, которая идёт за App\Http\Controllers .

    Метод PHP getContent () вернёт содержимое-строку ответа. Если ваш маршрут вернёт PHP View , вы можете получить его через свойство PHP $original :

    Для вызова HTTPS-маршрута можно использовать метод PHP callSecure () :

    Работа с базами данных

    Также Laravel содержит различные полезные инструменты для упрощения тестирования приложений, использующих БД. Во-первых, вы можете использовать функцию PHP seeInDatabase () для проверки наличия в БД данных, подходящих по набору критериев. Например, если мы хотим проверить, что в таблице users есть запись со значением в поле email равным sally@example.com , то можем сделать следующее:

    Само собой, метод PHP seeInDatabase () и другие подобные методы служат для удобства. Но вы можете использовать любые встроенные в PHPUnit методы проверок для дополнения своих тестов.

    Сброс базы данных после каждого теста

    Часто бывает полезно сбрасывать БД после каждого теста, чтобы данные из предыдущего теста не попадали в последующие тесты.

    Использование миграций

    Один из вариантов — откатывать БД после каждого теста и мигрировать её перед следующим тестом. В Laravel есть простой типаж DatabaseMigrations , который автоматически сделает это за вас. Просто используйте типаж в классе теста:

    Использование транзакций

    Другой вариант — обернуть каждый тест в транзакцию БД. И снова, в Laravel есть удобный типаж DatabaseTransactions , который автоматически сделает это за вас:

    Этот типаж обернёт в транзакцию только то соединения с БД, которое используется по умолчанию.

    Фабрики моделей

    При тестировании часто необходимо вставить несколько записей в БД перед выполнением теста. Вместо указания значений каждого поля тестовых данных вручную, Laravel позволяет определить набор атрибутов для каждой из ваших моделей Eloquent при помощи «фабрик» . Для начала посмотрим на файл database/factories/ModelFactory.php в вашем приложении. Изначально этот файл содержит одно определение фабрики:

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

    Конечно, вы можете добавить свои собственные дополнительные фабрики в файл ModelFactory.php . А для улучшения организации вы можете также создать файлы дополнительной фабрики. Например, вы можете создать файлы UserFactory.php и CommentFactory.php в папке database/factories .

    Множественные типы фабрик

    Иногда вам необходимо иметь несколько фабрик для одного класса модели Eloquent. Например, если нужна фабрика для пользователей «Administrator» вдобавок к обычным пользователям. Эти фабрики можно определить методом PHP defineAs () :

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

    Использование фабрик в тестах

    Когда вы определили свои фабрики, вы можете использовать их в своих тестах или файлах для заполнения БД, чтобы генерировать экземпляры модели с помощью глобальной функции PHP factory () . Давайте рассмотрим несколько примеров создания моделей. Сначала используем метод PHP make () , который создаёт модели, но не сохраняет их в БД:

    Если вы хотите переопределить некоторые из значений по умолчанию для своих моделей, вы можете передать массив значений в метод PHP make () . Будут заменены только указанные значения, а остальные будут иметь значения, определённые в фабрике:

    Также вы можете создать коллекцию моделей или создать модели заданного типа:

    Сохранение моделей фабрики

    Метод PHP create () не только создаёт экземпляры модели, но также сохраняет их в БД при помощи Eloquent-метода PHP save () :

    Вы можете переопределить атрибуты для модели, передав массив в метод PHP create () :

    Добавление отношений в модели

    Вы можете сохранить в БД даже несколько моделей. В данном примере мы даже прикрепим к созданным моделям отношение. При использовании метода PHP create () для создания нескольких моделей возвращается экземпляр коллекции, позволяя вам использовать любые удобные функции для работы с коллекцией, такие как PHP each () :

    Отношения и атрибуты замыкания

    Также вы можете прикрепить к моделям отношения с помощью атрибутов замыканий в определении вашей фабрики. Например, если вы хотите создать экземпляр User при создании Post , можно сделать так:

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

    Заглушки

    Заглушки событий

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

    В Laravel есть удобный метод PHP expectsEvents () , который проверяет возникновение ожидаемых событий, но предотвращает запуск всех обработчиков для этих событий:

    Методом PHP doesntExpectEvents () можно проверить, что заданные события не произошли:

    Если вы хотите предотвратить запуск всех обработчиков событий, используйте метод PHP withoutEvents () :

    Заглушки задач

    Иногда вам может понадобиться просто проверить, что определённые задачи запускаются вашими контроллерами при выполнении запросов в ваше приложение. Это позволяет вам тестировать ваши маршруты / контроллеры изолированно — отдельно от логики вашей задачи. А саму задачу вы можете протестировать в отдельном тест-классе.

    В Laravel есть удобный метод PHP expectsJobs () , который проверяет, что ожидаемые задачи вызываются, но при этом сами задачи выполняться не будут:

    Этот метод обнаруживает только те задачи, которые запускаются методами типажа DispatchesJobs или вспомогательной функцией PHP dispatch () . Он не обнаружит задачу, которая отправлена напрямую в PHP Queue :: push .

    Заглушки фасадов

    При тестировании вам может потребоваться отловить вызов к одному из фасадов Laravel. Например, рассмотрим такое действие контроллера:

    Вы можете отловить вызов фасада Cache с помощью метода PHP shouldReceive () , который вернёт экземпляр объекта-заглушки Mockery. Поскольку фасады извлекаются и управляются сервис-контейнером Laravel, их намного проще тестировать, чем обычный статический класс. Например, давайте отловим наш вызов фасада Cache :

    Не делайте этого для фасада Request . Вместо этого, передайте желаемый ввод вспомогательному HTTP-методу, такому как PHP call () или PHP post () , во время выполнения вашего теста.

    Рассмотрим такое действие контроллера:

    Вы можете отловить вызов класса Event с помощью метода PHP shouldReceive () этого фасада, который вернёт экземпляр объекта-заглушки Mockery.

    Заглушка фасада

    Не делайте этого для объекта Request . Вместо этого, передайте желаемый ввод методу PHP call () во время выполнения вашего теста.

    Вспомогательные методы

    Класс TestCase содержит несколько вспомогательных методов для упрощения тестирования вашего приложения.

    Установка и очистка сессий из теста

    Установка текущего авторизованного пользователя

    Вы можете установить текущего авторизованного пользователя с помощью метода PHP be () :

    Заполнение БД тестовыми данными

    Вы можете заполнить вашу БД начальными данными из теста методом PHP seed () :

    Больше информации на тему начальных данных доступно в разделе о миграциях.

    Обновление приложения

    Как вы уже возможно знаете, вы можете получить доступ к сервис-контейнеру вашего приложения с помощью PHP $this -> app из любого тестового метода. Этот экземпляр сервис-контейнера обновляется для каждого тестового класса. Если вы хотите вручную обновить приложение для определённого метода, вы можете использовать метод PHP refreshApplication () из этого тестового метода. Это приведет к сбросу дополнительных привязок, таких как заглушки, которые были помещены в сервис-контейнер после запуска теста.

    Комментарии (1)

    VadimLeader

    Нужно исправить /5.3/ на /v5/ в ссылках:
    Тестирование приложения, Тестирование БД и Заглушки.

    Источник

    Читайте также:  Что отражает принцип интерактивности дистанционного обучения тест