Testes são uma das partes mais importantes na concepção de um produto digital. Através deles obtemos garantia que determinada funcionalidade cumpre com os requisitos e atende ao cliente de maneira satisfatória.
Para alcançar esse objetivo devemos ter em mente que a entrega dos testes deve ser a mais rápida possível. Com na pirâmide de testes, os unitários são rápidos, baratos e fáceis de implementar.
Subindo o nível na pirâmide o grau de complexidade aumenta e por consequência sua execução também.
Esse post irá cobrir três partes: a apresentação do problema, o uso do xdebug e configurações extras no PHP.
Esse post é a resolução de um problema que estava enfrentando no meu time. Nossos testes no backend estavam demorando cerca de 32 minutos para rodar uma suíte com 600 testes e aproximadamente 2000 asserções , confesso que estava me incomodando profundamente.
Segunda-feira iniciei um processo de investigação nos testes e o primeiro passo foi detectar os testes lentos. Mas como iria fazer isso?
Identificando os testes lentos
Pesquisando na web encontrei o artigo do Elton Minetto, onde ele apresenta um pacote chamado phpunit-speedtrap. No post do Elton ele explica passo a passo como configurar o speedtrap.
O speedtrap executa juntamente com os testes e ao final da execução exibe os 10 primeiros testes mais lentos. Com um ponto de partida, continuei a investigar e juntamente com os desenvolvedores descobrimos que alguns testes estavam com um gargalo muito grande.
Por enquanto esses testes ainda não foram refatorados, mas está no nosso radar em corrigí-los para melhorar a performance dos testes.
Logo após isso, questionei os desenvolvedores sobre outros pontos que poderiam estar afetando a execução dos testes, eles me informaram que poderia ser a extensão de debug do PHP, chamada Xdebug que vem habilitada com o framework de testes que utilizamos, o PHPUnit.
Xdebug
Meu próximo passo foi pesquisar referências na web sobre a possível lentidão dos testes relacionado ao Xdebug. Para minha sorte encontrei diversas informações a respeito que mostravam como desabilitar ou até mesmo criar filtros para melhorar a performance dos testes.
Tentei desabilitar a extensão do Xdebug no arquivo php.ini, localmente porém não tive sucesso. Eu sabia que poderia realizar esse tipo de teste, mas iria precisar de um devops para configurar essa opção no servidor.
Mais uma vez o Elton Minetto salvando a pátria. Dessa vez ele aborda em um artigo publicado em 2016, a relação da lentidão dos testes com o Xdebug, a título de comparação ele conta no artigo que possuía uma base de código que sem o Xdebug habilita terminava em 1.08 , ao habilitar o Xdebug transformou para 22.26 minutos.
Ou seja, deve um aumento significativo. Infelizmente, a opção que era apresentada no artigo não consegui realizar pois precisaria de instalar um novo pacote no servidor. 😭
Conhecendo o xdebug-filter
Seguindo o lema de ser brasileiro e não desistir nunca, persisti em buscar outras alternativas para resolver meu problema. Encontrei um artigo no próprio site do Xdebug, explicando sobre a relação da cobertura de código com o Xdebug.
Ele é frequentemente usado em combinação com PHP_CodeCoverage como parte padrão do PHPUnit. O PHPUnit atribuí uma coleção de cobertura de código para o Xdebug que por sua vez, inicia a cobertura do código por meio do método xdebug_start_code_coverage() e interrompe através do xdebug_stop_code_coverage().
Para cada teste ele utiliza o xdebug_get_code_coverage() para recuperar os resultados.
Sua saída principal é detalha quais linhas nos quais os arquivos foram “atingidos” durante a execução do código.
Usando o Xdebug para tais atividades podemos ter um impacto adicional no desempenho, pois ele irá certificar de algumas informações como:
- analisar quais linhas de código possuem código executável;
- quais linhas de código podem ser atingidas;
- também podem instrumentar para descobrir quais ramificações;
- caminhos em funções e métodos foram seguidos.
Filtros para o resgate
Desde a versão 2.6 do Xdebug é possível criar filtros para a cobertura de código. Com um filtro, podemos incluir através de uma whitelist caminhos e prefixos que podem ser executados e também é possível negar através de uma blacklist.
Um exemplo, seria informar ao PHPUnit para coletar informações somente da sua pasta src onde fica sua base de código e os outros arquivos ele iria desconsiderar, assim, dependências do Composer, arquivos de configuração seria descartados na cobertura do código.
Existem algumas formas de criar esse filtro, eu criei o filtro baseado nesse artigo. Com um filtro configurado corretamente podemos esperar um ganho de velocidade duas vezes maior.
Esses são alguns relatos de pessoas que usaram os filtros:
This is the effect on the unit test suite of @opencfp with/out xdebug filter. 44.39 vs. 15.34 seconds. I'd call that "much faster". Great job @derickr!
(Integration tests were omitted) pic.twitter.com/LeNdaxBOOV— Holger W🌞ltersdorf (@hollodotme) January 17, 2018
Without the filter 6 seconds
With the filter about 4.9 secondsAnyway specifically you want me to beta test? :)
— Cees-Jan Kiewiet (@wyrihaximus) January 17, 2018
Antes de aplicar a técnica de filtros do Xdebug os testes estavam tinham uma execução de aproximadamente 32 minutos. 😱
Habilitando o filtro
Para criarmos o filtro basta utilizar dois comandos que irão reduzir drasticamente o tempo de execução dos testes.
O primeiro comando cria o arquivo xdebug-filter.php dentro do diretório build ele será gerado no diretório raiz da aplicação. Na minha pesquisa não verifiquei se podemos colocar ele em outro diretório.
# dump filter file
# Caso não tenha configurado globalmente o PHPUnit rode assim.
php vendor/bin/phpunit --dump-xdebug-filter build/xdebug-filter.php
# Configurado globalmente
phpunit --dump-xdebug-filter build/xdebug-filter.php
Após executar o comando do xdebug-filter sua saída é exatamente essa:
<?php
declare(strict_types=1);
if (!\function_exists('xdebug_set_filter')) {
return;
}
\xdebug_set_filter(
\XDEBUG_FILTER_CODE_COVERAGE,
\XDEBUG_PATH_WHITELIST,
['seu-path-aqui']
)
Executando os testes
Após a configuração iremos rodar nossa suíte de testes com o seguinte comando:
# Configuração local do PHPUnit
php vendor/bin/phpunit --prepend build/xdebug-filter.php --coverage-html build/coverage-report
# Configurado globalmente
phpunit --prepend build/xdebug-filter.php --coverage-html build/coverage-report
Com o arquivo do xdebug-filter iremos referenciá-lo nas configurações. Após aplicar as modificações do xdebug-filter, os testes executaram em 8 minutos.
Tive um ganho aproximadamente de 80% de execução! O processo agora está mais rápido e todo mundo feliz.
Dicas para o phpunit.xml
O arquivo phpunit.xml é o setup de configuração para suíte de testes que utilizam PHPUnit.
Vou mostrar alguns paramêtros que podem ser passados que irão melhorar a performance. Ele vem com uma série de paramêtros pré-configurados.
O primeiro paramêtro é o cacheResult="true", que permite o PHPUnit execute somente os testes que falharam anteriormente, com uma suíte grande testes isso é um ganho de tempo de resposta absurdo.
Podemos também usar os paramêtros stopOnFailure="true" que irá executar a suíte de testes até no momento que ela encontra alguma falha, bloqueando os restantes testes. O stopOnError="true" executa a suíte até encontrar algum erro bloqueando assim, a execução dos outros testes restantes.
O meu arquivo do phpunit.xml ficou da seguinte forma:
<?xml version="1.0" encoding="UTF-8">
<phpunit
backupGlobals="false"
backupStaticAttributes="false"
bootstrap="vendor/autoload.php"
cacheResult="true"
colors="true"
convertErrorsToExceptions="true"
convertNoticesToExceptions="true"
convertWarningsToExceptions="true"
processIsolation="false"
stopOnFailure="false"
stopOnError="false">
<testsuites></testsuites>
<testsuite name="Unit">
<directory suffix="Test.php">./tests/Unit</directory>
</testsuite>
<testsuite name="Feature">
<directory suffix="Test.php">./tests/Feature</directory>
</testsuite>
</testsuites>
<filter>
<whitelist addUncoveredFilesFromWhitelist="false" processUncoveredFilesFromWhitelist="true">
<directory suffix=".php">./app</directory>
<exclude>
<file>./app/Modules/User/routes.php</file>
</exclude>
</whitelist>
</filter>
</phpunit>
Conclusão
Ficou claro para mim que a curiosidade a gana para resolver esse problema foi o fator primordial, com isso tive vários aprendizados. Sempre seja curioso e tenta ao máximo melhorar as condições de trabalho do time.
Garantir a qualidade está também nos pequenos detalhes que podem refletir em grandes conquistas. Todas as referências de artigos que foram pesquisados estão logo abaixo.
Top comments (0)