Рейтинг: 5.0/5. на основе 2 оценок.
Пожалуйста, подождите...

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

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

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

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

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

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

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

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

Пример кода

Пример кода

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Команда Migrate

Команда Migrate

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

Модель 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.

Related Post

Один комментарий

  1. Антон-Ответить
    Январь 25, 2019 в 11:52 пп

    как раз тестирую Laravel приложение. Спасибо

    Пока нет оценок.
    Пожалуйста, подождите...

Оставить комментарий