Особенности тестирования Laravel приложений

Большое количество веб-приложений, которые мы тестируем в компании TestMatick, построены на бесплатном веб-фреймворке с открытым кодом – Laravel.

Можно смело утверждать о том, что Laravel полностью поддерживает тестовую среду PHPUnit, в самом что ни на есть ядре. Как мы помним, PHPUnit – это наиболее распространенный фреймворк для проведения тестирования работоспособности PHP кода. С его помощью можно создавать 2 вида тестов – модульные и функциональные.

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

Функциональные и модульные тесты

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

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

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

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

Пример кода

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

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

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

• Разработка GET запроса для доступа к веб-странице, где вводиться логин.
• Проверка того, отобразилась ли верная страница или нет.
• Создание POST запроса для моментальной отправки данных на веб-страницу с нашим логином.
• Проверка, успешно ли прошел созданный нами сеанс.

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

Создание предварительных условий

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

В первую очередь нам нужно создать рабочую модель post, а также связанную с ней миграцию. Для этого нужно прописать специальную команду artisan, которая как раз и отвечает за разработку модели post:

Специальная команда artisan

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

Разработанный класс модели post должен выглядеть так:

Разработанный класс модели post

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

Расположение файла миграции

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

Структура файла миграции

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

Специальный столбец

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

Команда Migrate

Затем нужно выполнить полную замену использованной модели post на такое содержание:

Модель Post

Только что у нас получилось добавить специальный метод accesor, с помощью которого можно редактировать заголовки сообщений, то есть выполнять те манипуляции, которые нужны нам в данном тестовом примере. Все это в полной мере касается и рассматриваемой ранее модели post.

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

Файловый контейнер

Функциональный тестовый сценарий

Внутри метода index нам нужно постараться извлечь идентификатор сообщения из набора параметров нашего запроса с последующей загрузкой объектной модели post.

Указываем путь к требуемому файлу:

Путь к требуемому файлу

Модульное тестирование приложения в Laravel

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

Artisan являет собой интерфейс командной строки, с помощью которого тестировщики могут «играть» классическим шаблонным классом своего модульного теста.

Давайте вместе выполним такую команду для того, чтобы создать специальный класс AccessorTest. В данном случае очень важно наличие слова unit, с помощью которого как раз и создается модульный текст-кейс, расположенный в указанной директории tests/unit.

Модульный текст-кейс

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

Класс

Класс

Разбавим все «полезным» программным кодом:

Программный код

Как нам видно, программный код полностью совпадает с тем, что мы можем наблюдать в любом ядре PHP. Нам только потребовалось импортировать все зависимости кода от утилиты Laravel, с помощью которых мы можем подключать все необходимые для теста API.

С модульным тестированием в Laravel разобрались!

Функциональное тестирование

Для начала нужно создать предварительные условия, что работают в среде функционального теста (в нашем случае AccessorTest). Так как мы не применяем функциональное выражение unit, вся наша работа будет рассматриваться как многофункциональный тестовый кейс с перемещением в специальный каталог – tests/feature.

С его помощью будет создан необходимый класс:

Необходимый класс

Теперь меняем все на нужный нам программный код:

Необходимый программный код

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

Что у нас в итоге получилось: во-первых, мы смогли извлечь пост из указанной базы данных и знаем, что изменится значение внутри $db_post_title. Затем у нас появится возможность имитировать «GET» запрос и охватить полученный ответ в переменную $response.

Потом мы проанализировали код ответа внутри переменной $response с ожидаемым ответом. При наших исходных данных это должно быть число 200, ведь мы должны получить реальный отчет на запрос GET.

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

Пару слов об интеграционной проверке в Laravel

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

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

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

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

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

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