- •Глава 1. Теоретические основы технологий symfony framework 7
- •Глава 2. Создание приложения на основе технологий symfony framework 51
- •Введение
- •Глава 1. Теоретические основы технологий symfony framework
- •1.1. История развития веб-технологий и существующие проблемы
- •1.2. Обзор типовых решений в области веб-разработки
- •1.3. Модель mvc и ооп в веб-программировании
- •1.4. Назначение и установка Symfony Framework
- •1.5. Структура Symfony Framework
- •1.5.1. Конфигурация
- •1.5.2. Бандлы
- •1.5.3. Сущности Doctrine
- •1.5.4. Маршрутизация
- •1.5.5. Контроллеры
- •1.5.6. Шаблонизатор Twig
- •1.5.7. Генерация форм и валидация
- •1.5.8. Безопасность
- •1.5.9. Сервисы
- •1.5.10. Консольные команды
- •1.5.11. Механизмы тестирования
- •1.6. Развертывание приложения Symfony
- •Глава 2. Создание приложения на основе технологий symfony framework
- •2.1. Постановка задачи
- •2.2. Настройка develop-сервера и установка Symfony
- •2.3. Установка дополнительных библиотек через composer
- •2.4. Вёрстка шаблона, npm, webpack
- •2.5. Генерация сущностей и форм
- •2.6. Определение маршрутов и контроллеров
- •2.7. Создание и настройка сервисов
- •2.8. Написание консольных команд и заданий cron
- •2.9. Тестирование
- •2.10. Перенос проекта на production-сервер
- •Заключение
- •Список литературы
- •Приложения
1.5.10. Консольные команды
Symfony Framework предоставляет множество команд через bin/console скрипт (например, команда bin/console cache:clear). Эти команды создаются с помощью компонента Console. Он так же используется для создания пользовательских команд.
Команды определяются в классах, которые должны быть созданы в директории Command бандла (например, AppBundle\Command), и их имена должны заканчиваться суффиксом Command.
Внутри данных классов имеется возможность получения сервисов из контейнера, добавление аргументов (методом addArgument), вывод в консоль (методом writeln), определения названия (setName), описания (setDescription) и помощи (setHelp) по команде.
Команды имеют три метода жизненного цикла, которые вызываются при выполнении команды:
initialize() (необязательный)
Этот метод выполняется до interact() и execute() методов. Его основная цель - инициализировать переменные, используемые в остальных командных методах.
interact() (необязательный)
Этот метод выполняется после initialize() и до execute(). Его цель - проверить, отсутствуют ли некоторые из параметров / аргументов и интерактивно спросить у пользователя эти значения. Это последнее место, где можно запросить отсутствующие параметры / аргументы. После этой команды отсутствующие параметры / аргументы приведут к ошибке.
execute() (обязательный)
Этот метод выполняется после interact() и initialize(). Он содержит логику, которую необходимость выполнить.
1.5.11. Механизмы тестирования
Symfony интегрируется с независимой библиотекой, называемой PHPUnit. Каждый тест - будь то unit-тест или функциональный тест - это класс PHP, который должен находиться в каталоге tests/ бандла. PHPunit конфигурируется в файле phpunit.xml.dist в корне проекта Symfony.
Unit-тест (модульный тест) - это тест для одного класса PHP, также называемого unit. Написание модульных тестов Symfony ничем не отличается от написания стандартных модульных тестов PHPUnit. Как правило таким тестам подвергаются классы низкого уровня. Это означает, что контроллеры и сервисы, обладающие большим количеством зависимостей сложно поддаются модульному тестированию, так как основная его идея – проверка конкретных методов и участков кода на соответствие ожидаемым значениям. В листинге 15 приведёт простейший класс и пример возможного тестирования с помощью PHPUnit.
// src/AppBundle/Util/Calculator.php
namespace AppBundle\Util;
class Calculator
{
public function add($a, $b)
{
return $a + $b;
}
}
// tests/AppBundle/Util/CalculatorTest.php
namespace Tests\AppBundle\Util;
use AppBundle\Util\Calculator;
use PHPUnit\Framework\TestCase;
class CalculatorTest extends TestCase
{
public function testAdd()
{
$calc = new Calculator();
$result = $calc->add(30, 12);
// Отображает, что тест пройден успешно
$this->assertEquals(42, $result);
}
}
Листинг 15. Пример описания unit-теста
Для запуска всех тестов в проекте используется консольная команда «phpunit».
Функциональные тесты проверяют интеграцию различных уровней приложения (от маршрутизации до представления). Они ничем не отличаются от модульных тестов, так как используют PHPUnit, но они имеют специфический рабочий процесс:
Создать запрос;
Проверить ответ;
Нажать ссылку или отправить форму;
Проверить ответ;
Повторить.
Функциональные тесты - это простые PHP-файлы, которые обычно располагаются в tests/AppBundle/Controller каталоге бандла. Например, для тестирования страниц, обрабатываемых PostController классом, создаётся новый PostControllerTest.php файл, который расширяет специальный WebTestCase класс. Пример такого теста представлен в листинге 16.
<?
// tests/AppBundle/Controller/PostControllerTest.php
namespace Tests\AppBundle\Controller;
use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;
class PostControllerTest extends WebTestCase
{
public function testShowPost()
{
// Создаёт клиента
$client = static::createClient();
// Создаёт get-запрос к странице /post/hello-world
$crawler = $client->request('GET', '/post/hello-world');
// При наличие на странице текста «Hello World» тест считается успешно пройденным
$this->assertGreaterThan(
0,
$crawler->filter('html:contains("Hello World")')->count()
);
}
}
Листинг 16. Пример функционального теста
Для запуска функциональных тестов класс WebTestCase загружает ядро приложения. При тестировании данным способом доступно множество методов для имитации поведения реального пользователя, такие как нажатие на кнопку или ссылку, отправка формы, загрузка файлов и т. д. Основной идей такого тестирования является поиск соответствий фактического поведения приложения с ожидаемым. Это достигается путём полной эмуляции работы ядра Symfony, вместе со всеми её сервисами, эмуляции клиента, а также сравнения статусов ответа, HTML-тегов, атрибутов форм, перехода по ссылкам с ожидаемыми (правильными).
