Testes em andamento
A parte mais visível do Nette Tester é o corredor de teste da linha de comando. Ele é extremamente rápido e robusto porque inicia automaticamente todos os testes como processos separados em paralelo em várias roscas. Ele também pode funcionar sozinho no chamado modo relógio.
O teste de teste Nette Tester é invocado a partir da linha de comando. Como parâmetro, passaremos no diretório de testes. Para o diretório atual, basta entrar um ponto:
vendor/bin/tester .
Quando invocado, o test runner escaneará o diretório especificado e todos os subdiretórios e procurará por testes, que
são os arquivos *.phpt e *Test.php. Ele também lê e avalia suas anotações para saber quais delas e como executá-las.
Em seguida, ele executará os testes. Para cada teste feito, o corredor imprime um caractere para indicar o progresso:
.– teste aprovados– o teste foi puladoF– teste falhou
O resultado pode ser parecido:
_____ ___ ___ _____ ___ ___
|_ _/ __)( __/_ _/ __)| _ )
|_| \___ /___) |_| \___ |_|_\ 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)
Quando você o executa novamente, ele faz os primeiros testes que falharam durante a execução anterior, assim você saberá imediatamente se corrigiu o erro.
O código de saída do testador é zero se ninguém falhar. Caso contrário, não é zero.
O Tester executa processos PHP sem php.ini. Mais detalhes na seção php.ini próprio.
Opções da Linha de Comando
Obtemos uma visão geral das opções de linha de comando executando o Tester sem parâmetros ou com a opção
-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> (por exemplo, -o junit:output.xml)
Especifique um ou mais formatos de saída com um nome de arquivo opcional.
-w | --watch <path> Watch directory.
-i | --info Show tests environment info and exit.
--setup <path> Script for runner setup.
--temp <path> Caminho para o diretório temporário. Padrão por 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 testes. Por padrão, ele é php.
tester -p /home/user/php-7.2.0-beta/php-cgi tests
-c <path>
Especifica qual php.ini será usado ao executar testes. Por padrão, nenhum php.ini é usado. Consulte o próprio php.ini para mais informações.
-C
É utilizado um sistema de todo o sistema php.ini. Assim, na plataforma UNIX, todos os arquivos
/etc/php/{sapi}/conf.d/*.ini também são utilizados. Veja a seção php.ini
Próprio.
-d <key=value>
Define o valor da diretiva de configuração PHP para testes. O parâmetro pode ser usado várias vezes.
tester -d max_execution_time=20
-s
Serão mostradas informações sobre testes pulados.
--stop-on-fail
O testador interrompe os testes após o primeiro teste reprovado.
-j <num>
Os testes são realizados em um <num> precessos paralelos. O valor padrão é 8. Se desejarmos realizar
testes em série, usamos o valor 1.
-o <console|console-lines|tap|junit|log|none>
Formato de saída. O padrão é o formato do console. Você pode especificar o nome do arquivo no qual a saída será
gravada (por exemplo, -o junit:output.xml). A opção -o pode ser repetida várias vezes para gerar
vários formatos de uma só vez.
console: o mesmo que o padrão, mas o logotipo ASCII não é impresso neste casoconsole-lines: semelhante ao console, mas o resultado de cada teste é listado em uma linha separada com mais informaçõestap: Formato TAP apropriado para o processamento de máquinasjunit: formato JUnit XML, apropriado também para processamento em máquinaslog: Exibe o progresso do teste. Todos os testes falhos, ignorados e também os bem-sucedidosnone: nada é impresso
"'-w | –watch <path>''
O Tester não termina após a conclusão dos testes, mas ele continua rodando e observando arquivos PHP em determinado diretório. Quando alterado, ele executa os testes novamente. O parâmetro pode ser usado várias vezes se quisermos monitorar vários diretórios.
É útil durante a refatoração de uma biblioteca ou a depuração de testes.
tester --watch src tests
"‚-i | –info‘
Ele mostra informações sobre um ambiente de teste em execução. 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 carrega dado script PHP no início. A variável Tester\Runner\Runner $runner está disponível nela.
Vamos assumir o arquivo tests/runner-setup.php:
$runner->outputHandlers[] = new MyOutputHandler;
e nós dirigimos o Tester:
tester --setup tests/runner-setup.php tests
--temp <path>
Define um caminho para o diretório de arquivos temporários do Tester. O valor padrão é retornado por
sys_get_temp_dir(). Quando o valor padrão não for válido, você será notado.
Se não tivermos certeza de qual diretório é utilizado, podemos executar o Tester com o parâmetro --info.
-colors 1|0
O Tester detecta um terminal colorível por padrão e coloriza sua saída. Esta opção está sobre a autodetecção. Podemos
definir a coloração globalmente através de uma variável de ambiente de sistema NETTE_TESTER_COLORS.
--coverage <path>
O teste irá gerar um relatório com uma visão geral de quanto o código fonte é coberto pelos testes. Esta opção requer a extensão PHP Xdebug ou PCOV habilitada, ou PHP 7 com o PHPDBG SAPI, que é mais rápido. A extensão do arquivo de destino determina o formato do conteúdo. HTML ou Clover XML.
tester tests --coverage coverage.html # HTML report tester tests --coverage coverage.xml # Clover XML report
A prioridade para escolher o mecanismo de coleta é seguir:
- PCOV
- PHPDBG
- Xdebug
Testes extensivos podem falhar durante a execução do PHPDBG devido à exaustão da memória. A coleta de dados de cobertura
é uma operação que consome memória. Nesse caso, chamar o Tester\CodeCoverage\Collector::flush() dentro de um
teste pode ajudar. Ele irá lavar os dados coletados em um arquivo e liberar a memória. Quando a coleta de dados não está em
andamento, ou Xdebug é usado, a chamada não tem efeito.
Um exemplo de relatório HTML com cobertura de código.
--coverage-src <path>
Usamo-lo com a opção --coverage simultaneamente. A opção <path> é um caminho para
o código fonte para o qual geramos o relatório. Ele pode ser usado repetidamente.
Php.ini próprio
O Tester executa processos PHP com a opção -n, o que significa que nenhum php.ini é carregado
(nem mesmo o de /etc/php/conf.d/*.ini em UNIX). Ele garante o mesmo ambiente para a execução dos testes, mas
também desativa todas as extensões externas do PHP comumente carregadas pelo sistema PHP.
Se você quiser manter a configuração do sistema, use o parâmetro -C.
Se você precisar de algumas extensões ou algumas configurações especiais do INI, recomendamos criar um arquivo próprio
php.ini e distribuí-lo entre os testes. Em seguida, executamos o Tester com a opção -c, por exemplo,
tester -c tests/php.ini. O arquivo INI pode ser parecido:
[PHP]
extension=php_pdo_mysql.dll
extension=php_pdo_pgsql.dll
memory_limit=512M
Executando o Tester com um sistema php.ini em UNIX, por exemplo tester -c /etc/php/cgi/php.ini, não
carrega outros INI de /etc/php/conf.d/*.ini. Esse é o comportamento do PHP, não o do Tester.