Архив рубрики: тестирование

Тестирование PHP-приложений из Geany

Когда-то я настраивал запуск тестов перловых Mojolicious-приложений прямо из IDE Geany. Потом довелось попробовать микрофреймворк Slim для PHP — ну да, работает, хотя тесты там более многословные по сравнению с перловыми.

А теперь попробуем настроить Geany для запуска тестов в современных PHP-приложениях — например, для использующих уже упомянутый Slim. Для запуска тестов в PHP существует PHPUnit — это не единственный инструмент, хоть и весьма популярный. Настройки тестирования зависят от проекта — в каждом проекте они могут быть своими. В Geany 1.27 настройки вызываются через меню: Project → Properties → вкладка Build либо Build → Set Build Commands:

  1. Задаём имя команды, под которым она будет отображаться в меню — нажимаем на пустую кнопку в столбце Label (в моём примере это была вторая сверху кнопка, на которой теперь написано Test).
  2. Указываем в столбце Command путь к PHPUnit — он может лежать, например, в подкаталоге vendor/bin относительно корня приложения. В случае, если он лежит внутри проекта, базовый путь проекта можно записать как %p.
  3. В столбце Working directory указываем путь к корневой папке приложения.
  4. В строке Error regular expression указываем регулярное выражение для поиска ошибок:
    ^(.+):(\d+)$
    PHPUnit выводит в сообщении об ошибке разделённые двоеточием полный путь к файлу и номер строки с ошибкой. Если даблкликнуть^W дважды щёлкнуть по сообщению, можно быстро перейти к соответствующей строке, кроме того, все строки, вызвавшие ошибки тестирования, выделяются подчёркиванием красной волнистой линией.

После настройки тесты можно будет запускать кучей разных способов: через меню, кликом по кнопке с кирпичом, а также с клавиатуры (по умолчанию — клавишей F9).

Подсчёт числа DOM-элементов при тестировании через Test::Mojo

Модуль Test::Mojo позволяет проверить, нашлось ли нужное количество DOM-элементов:

$t = $t->element_count_is('div.foo[x=y]', 5);
$t = $t->element_count_is('html body div', 30, 'thirty elements');

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

$t->get_ok("$ROOT/some.xml");
my @items = $t->tx->res->dom->find('rss channel item')->each;
ok scalar @items > 42, 'More than 42 items in some.xml';

Инструменты разные — методы похожие

Попробовал решить одну из рабочих задач, применив нелюбимый язык PHP в комплекте с современными инструментами — получилось близко к тому, что делал сравнительно недавно на перле, с некоторыми отличиями:

  • Вместо  перла — PHP,
  • Модули тоже лежат рядом со своим кодом, но управляются не картоном, а через composer,
  • Композер и тесты может запустить (composer test), и отладочный сервер (composer start). Но можно для однообразия для обоих языков сделать Makefile и выполнять нужные действия командой make. Например, у меня запуск тестов — всегда make test, чтобы не путаться.
  • Вместо Mojolicious::Lite — микрофреймворк Slim. Для быстрого старта — Slim-Skeleton.
  • В шаблонах вместо Embedded Perl — Twig.
  • Если сайт работает через PHP-FPM, то нет нужды пинать демона каждый раз, как обновится код — он сам обрабатывает подобную ситуацию. Развёртывание свежей версии простого веб-приложения сводится к трём действиям: обновление рабочей копии (svn up либо git pull), разрешение зависимостей (composer install) и на всякий случай запуск тестов.

Слон и код

Практика показала, что разобраться с подобным комбайном можно достаточно быстро. Код при этом получается чуть более многословным, чем в Mojo, но всё равно компактным и понятным.

Тестирование перловых mojolicious-приложений в Geany

Программировать, используя какую-нибудь могучую интегрированную среду разработки (IDE) — хорошо и зачастую удобно: там «из коробки» могут предоставляться различные удобные штуковины — компиляция, отладка, тестирование, работа с системами контроля версий. Однако некоторые системы при всём своём могуществе оказываются не совсем подходящими — например, могут много весить и сильно тормозить. Приходится выбирать что-нибудь полегче, например, Geany.

В Geany есть (в том числе и средствами дополнительных модулей) всякое:

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

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

Итак, у нас есть:

  • IDE Geany,
  • Веб-приложение, написанное на языке Perl с использованием фреймворка Mojolicious и системы управления модулями carton,
  • Желание запускать тесты почаще и попроще, без лишних переключений из редактора в терминал.

Geany позволяет для каждого проекта задать список действий: как общих для всего проекта, так и специфичных для конкретного типа файлов — найти настроки можно в меню Project → Properties → вкладка Build либо Build → Set Build Commands.

Настройки команд в Geany

По умолчанию для перловых скриптов есть только одно действие — компиляция, а по факту — проверка синтаксиса. Можно исправить эту команду, научив её работать с картоном.

Пойдём дальше — научим Geany прогонять тесты из текущего файла. В Mojolicious тесты представляют собой перловые файлы, имеющие расширение .t и лежащие в каталоге t/. Для того, чтоб, видя в редакторе открытый файл с тестами, прогнать тесты, в настройках придётся добавить путь к корневой папаке приложения. Чтоб не писать путь целиком, можно воспользоваться шаблонами. В документации пишут:

The first occurrence of each of the following character sequences in each of the command and working directory fields is substituted by the items specified below before the command is run.

  • %d — substituted by the absolute path to the directory of the current file.
  • %e — substituted by the name of the current file without the extension or path.
  • %f — substituted by the name of the current file without the path.
  • %p — if a project is open, substituted by the base path from the project.
  • %l — substituted by the line number at the current cursor position.

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

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

Пробуем выполнить тест — в окно Compiler выводятся результат выполнения. Если есть ошибки, они будут выделены и в этом окне, и в исходном коде теста.

Результат тестирования в Geany

Сфинкс спрятался? Сделаем туннель, но ненадолго

Ситуация: жил-был Сфинкс (поисковая система Sphinx) на старом сервере, да пришла пора на новый переезжать. Нужный порт на новом месте доступен скриптам, что живут там же, а снаружи — нет и не надейтесь. Результат — кое-где тесты покраснели.

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

ssh -L 9312:localhost:9312 server.name

Однако в таком виде она неудобна: команду надо запускать в одном окне терминала, тесты — в соседнем, а после завершения тестов надо ещё и закрывать SSH-сессию в первом окне.

man ssh

В инструкции (man ssh) пишут:

SYNOPSIS
     ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address]
         [-c cipher_spec] [-D [bind_address:]port] [-E log_file]
         [-e escape_char] [-F configfile] [-I pkcs11]
         [-i identity_file] [-J [user@]host[:port]] [-L address]
         [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option]
         [-p port] [-Q query_option] [-R address] [-S ctl_path]
         [-W host:port] [-w local_tun[:remote_tun]]
         [user@]hostname [command]
...
     -f      Requests ssh to go to background just before
             command execution.

То есть, ssh позволяет и команду выполнить, и перед этим уйти в фоновый режим. Приме́ним полученные знания:

ssh -fL 9312:localhost:9312 server.name sleep 5

Такая команда откроет туннель, не выводя ничего в терминал, подождёт пять секунд и закроется — почти то, что надо!

Осталось исключить рытьё тоннелей на сервере

test `uname -n` != 'server' && ssh -fL 9312:localhost:9312 server.name sleep 5

и скрестить открытие туннеля с тестированием. Тесты в перловом веб-приложении, написанном с использованием микрофреймворка Mojolicious::Lite, могут вызываться различными путями — и как ./application.pl test, и командой prove, и как-нибудь ещё — я, например, обычно создаю Makefile с нужными мне задачами и тесты выполняю командой make test — мне так удобнее. Чтоб не рассматривать все возможные варианты тестирования, надо поместить открытие туннеля прямо в тест. Если конфигурация приложения хранится в каком-либо отдельном файле (YAML хорошо для этого подходит — в Моджолишисе есть плагин для чтения ЯМЛ-конфигов), можно команду открытия туннеля хранить рядом с остальными настройками — это лучше, чем пихать её в тест. А в тесте останется лишь вызвать её после создания объекта Test::Mojo:

my $t = Test::Mojo->new();

system($t->app->config->{'sphinx'}->{'tunnel'}) == 0
or warn "Cannot open SSH tunnel to Sphinx: $!";

Тесты зеленеют, можно спокойно идти заниматься музыкой 🙂

P.S. Если вместо system применить функцию exec, то тест не будет выполняться до тех пор, пока не закроется туннель — тест будет ждать завершения дочернего процесса и в итоге так и останется красным.

Тесты зеленеют

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

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

Попутно выяснил странную штуку: почему-то перловое приложение на Mojolicious::Lite всегда запускает тесты в режиме отладки вместо боевого несмотря на явное указание

./app.pl test -m deployment

Хотя раньше, вроде, разница была. Или не было?

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

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