Executando Testes
A parte mais visível do Nette Tester é o executor de testes a partir da linha de comando. É extraordinariamente rápido e robusto, pois executa automaticamente todos os testes como processos separados e em paralelo em múltiplas threads. Também pode se executar sozinho no chamado modo watch.
Chamamos o executor de testes a partir da linha de comando. Como parâmetro, indicamos o diretório com os testes. Para o diretório atual, basta digitar um ponto:
vendor/bin/tester .
O executor de testes pesquisa o diretório especificado e todos os subdiretórios e procura por testes, que são os arquivos
*.phpt e *Test.php. Ao mesmo tempo, lê e avalia suas anotações,
para saber quais deles e como executar.
Em seguida, executa os testes. Durante a execução dos testes, exibe continuamente os resultados no terminal como caracteres:
.– teste passous– teste foi pulado (skipped)F– teste falhou (failed)
A saída pode ter a seguinte aparência:
_____ ___ ___ _____ ___ ___
|_ _/ __)( __/_ _/ __)| _ )
|_| \___ /___) |_| \___ |_|_\ v2.5.2
Note: No php.ini is used.
PHP 8.3.2 (cli) | php -n | 8 threads
........s..........................
OK (35 tests, 1 skipped, 1.7 seconds)
Ao executar repetidamente, ele primeiro executa os testes que falharam na execução anterior, para que você saiba imediatamente se conseguiu corrigir o erro.
Se nenhum teste falhar, o código de retorno do Tester é zero. Caso contrário, o código de retorno é diferente de zero.
O Tester executa os processos PHP sem php.ini. Detalhado na seção #custom-php-ini.
Parâmetros da linha de comando
Obtemos uma visão geral de todas as opções da linha de comando executando o Tester sem parâmetros ou com o parâmetro
-h:
_____ ___ ___ _____ ___ ___
|_ _/ __)( __/_ _/ __)| _ )
|_| \___ /___) |_| \___ |_|_\ v2.5.2
Usage:
tester [options] [<test file> | <directory>]...
Options:
-p <path> Specify PHP interpreter to run (default: php).
-c <path> Look for php.ini file (or look in directory) <path>.
-C Use system-wide php.ini.
-d <key=value>... Define INI entry 'key' with value 'value'.
-s Show information about skipped tests.
--stop-on-fail Stop execution upon the first failure.
-j <num> Run <num> jobs in parallel (default: 8).
-o <console|console-lines|tap|junit|log|none> (e.g. -o junit:output.xml)
Specify one or more output formats with optional file name.
-w | --watch <path> Watch directory.
-i | --info Show tests environment info and exit.
--setup <path> Script for runner setup.
--temp <path> Path to temporary directory. Default by sys_get_temp_dir().
--colors [1|0] Enable or disable colors.
--coverage <path> Generate code coverage report to file.
--coverage-src <path> Path to source code.
-h | --help This help.
-p <path>
Especifica o binário PHP que será usado para executar os testes. O padrão é php.
tester -p /home/user/php-7.2.0-beta/php-cgi tests
-c <path>
Especifica qual php.ini será usado ao executar os testes. Por padrão, nenhum php.ini é usado. Mais na seção
#custom-php-ini.
-C
Usa o php.ini do sistema. No UNIX, também todos os arquivos INI relevantes
/etc/php/{sapi}/conf.d/*.ini. Mais na seção #custom-php-ini.
-d <key=value>
Define o valor da diretiva de configuração PHP para os testes. O parâmetro pode ser usado várias vezes.
tester -d max_execution_time=20
-s
Exibe informações sobre os testes pulados.
--stop-on-fail
O Tester interrompe os testes no primeiro teste que falhar.
-j <num>
Especifica quantos processos paralelos com testes serão iniciados. O valor padrão é 8. Se quisermos que todos os testes sejam executados em série, usamos o valor 1.
-o <console|console-lines|tap|junit|log|none>
Define o formato da saída. O padrão é o formato para console. Você pode especificar o nome do arquivo no qual a saída
será escrita (por exemplo, -o junit:output.xml). A opção -o pode ser repetida várias vezes para
gerar vários formatos de uma vez.
console: idêntico ao formato padrão, mas neste caso o logo ASCII não é exibidoconsole-lines: semelhante ao console, mas o resultado de cada teste é listado em uma linha separada com informações adicionaistap: Formato TAP adequado para processamento por máquinajunit: formato XML JUnit, também adequado para processamento por máquinalog: Saídas do andamento dos testes. Todos os testes malsucedidos, pulados e também bem-sucedidosnone: nada é exibido
-w | --watch <path>
Após a conclusão dos testes, o Tester não termina, mas permanece em execução e monitora os arquivos PHP no diretório especificado. Ao detectar uma alteração, executa os testes novamente. O parâmetro pode ser usado várias vezes se quisermos monitorar vários diretórios.
É útil ao refatorar uma biblioteca ou depurar testes.
tester --watch src tests
-i | --info
Exibe informações sobre o ambiente de execução para os testes. Por exemplo:
tester -p /usr/bin/php7.1 -c tests/php.ini --info PHP binary: /usr/bin/php7.1 PHP version: 7.1.7-1+0~20170711133844.5+jessie~1.gbp5284f4 (cli) Code coverage engines: (not available) Loaded php.ini files: /var/www/dev/demo/tests/php.ini PHP temporary directory: /tmp Loaded extensions: Core, ctype, date, dom, ereg, fileinfo, filter, hash, ...
--setup <path>
O Tester, ao iniciar, carrega o script PHP especificado. Nele, a variável Tester\Runner\Runner $runner está
disponível. Suponha o arquivo tests/runner-setup.php com o conteúdo:
$runner->outputHandlers[] = new MyOutputHandler;
Executamos o Tester:
tester --setup tests/runner-setup.php tests
--temp <path>
Define o caminho para o diretório de arquivos temporários do Tester. O valor padrão é retornado por
sys_get_temp_dir(). Se o valor padrão não for válido, você será avisado.
Se não tivermos certeza de qual diretório está sendo usado, executamos o Tester com o parâmetro --info.
--colors 1|0
Por padrão, o Tester detecta um terminal colorido e colore sua saída. Esta opção substitui a autodeteção. Globalmente,
podemos definir a coloração com a variável de ambiente do sistema NETTE_TESTER_COLORS.
--coverage <path>
O Tester gera um relatório com uma visão geral de quanto do código-fonte os testes cobrem. Esta opção requer a extensão PHP instalada Xdebug, ou PCOV, ou PHP 7 com PHPDBG SAPI, que é mais rápido. A extensão do arquivo de destino determina seu formato. Seja HTML ou Clover XML.
tester tests --coverage coverage.html # Relatório HTML tester tests --coverage coverage.xml # Relatório Clover XML
A prioridade de seleção do mecanismo é a seguinte:
- PCOV
- PHPDBG
- Xdebug
Ao usar PHPDBG, podemos encontrar falhas nos testes devido ao esgotamento da memória em testes extensos. A coleta de
informações sobre o código coberto consome muita memória. Neste caso, a chamada
Tester\CodeCoverage\Collector::flush() dentro do teste nos ajuda. Ela escreve os dados coletados no disco e libera a
memória. Se a coleta de dados não estiver ocorrendo, ou se o Xdebug estiver sendo usado, a chamada não tem efeito.
Exemplo de relatório HTML com cobertura de código.
--coverage-src <path>
Usamos simultaneamente com a opção --coverage. <path> é o caminho para os códigos-fonte
para os quais o relatório é gerado. Pode ser usado repetidamente.
php.ini personalizado
O Tester executa os processos PHP com o parâmetro -n, o que significa que nenhum php.ini é
carregado. No UNIX, nem mesmo os de /etc/php/conf.d/*.ini. Isso garante um ambiente consistente para a execução dos
testes, mas também desativa todas as extensões PHP normalmente carregadas pelo PHP do sistema.
Se você deseja manter o carregamento dos arquivos php.ini do sistema, use o parâmetro -C.
Se você precisar de algumas extensões ou configurações INI especiais para os testes, recomendamos a criação de seu
próprio arquivo php.ini, que será distribuído com os testes. O Tester é então executado com o parâmetro
-c, por exemplo, tester -c tests/php.ini tests, onde o arquivo INI pode ter a seguinte aparência:
[PHP]
extension=php_pdo_mysql.dll
extension=php_pdo_pgsql.dll
memory_limit=512M
A execução do Tester no UNIX com o php.ini do sistema, por exemplo, tester -c /etc/php/cli/php.ini
não carrega outros INIs de /etc/php/conf.d/*.ini. Isso é uma característica do PHP, não do Tester.