Testes estáticos do PHP para desenvolvedores front-end

Estou tentando adicionar o teste estático do PHP no Frontools para simplificar e melhorar o processo de teste e, se for possível aumentar o desempenho, b / c leva tanto tempo para obter resultados.

GH Issue - https://github.com/SnowdogApps/magento2-frontools/issues/45

Não estou familiarizado com as bibliotecas / ferramentas de teste do PHP, portanto, faça algumas perguntas para você:

1. Existe alguma razão para o M2 usar as bibliotecas de teste (PHPUnit e PHP_CS) de 2014 em vez de uma nova?
2. É normal que a saída desse teste pareça uma bagunça e é difícil entender o que e onde aconteceu algo errado? Comparo-o com a saída de testes de qualidade de código para CSS / JS e é um pesadelo. Existe algum repórter melhor disponível ou alguma outra maneira de obter um relatório significativo, em vez de algo parecido com um retorno do PHP?
3. Existe alguma razão para ser tão lento? Demora de 7 a 8 minutos para analisar os arquivos de modelo. A maioria dos testes de front-end, na pior das hipóteses, leva alguns segundos; portanto, não há como obter feedback ao vivo sobre problemas.
4. Como executar esse tipo de teste quando temos um único módulo (ou seja, tema), não toda a instância do Magento 2 (testes de CI)?
5. Parece que o PHP_CS já possui um invólucro simples para o Gulp, mas não tenho certeza de onde a configuração está armazenada. Está no arquivo /.php_cs?

Vou apenas dar-lhe meus pensamentos sobre isso, posso estar errado em alguns pontos, mas talvez isso esclareça algumas coisas:

Existe alguma razão para o M2 usar as bibliotecas de teste (PHPUnit e PHP_CS) de 2014 em vez de uma nova?

Meu palpite é que, como o desenvolvimento do Magento 2 começou há alguns anos atrás, a equipe usou a biblioteca que estava disponível naquele momento. Como eles escreveram muitos testes no Magento 2, eles provavelmente mantêm a versão usada no momento em que escreveram os primeiros testes para não interromper os testes . Certamente eles poderiam atualizar isso em algum momento da versão principal. Agora você pode fazer solicitações de recursos no fórum sobre isso: https://community.magento.com/t5/Magento-2-Feature-Requests-and/idb-p/feature-requests

É normal que a saída deste teste pareça uma bagunça e é difícil entender o que e onde algo errado acontece? Comparo-o com a saída de testes de qualidade de código para CSS / JS e é um pesadelo. Existe algum repórter melhor disponível ou outra maneira de obter um relatório significativo, em vez de algo parecido com um retorno do PHP?

Bem, sim, a saída padrão do PHPUnit não é super agradável. A maior parte do IDE suporta PHPUnit e fornece umaMelhormelhor saída . Por exemplo, aqui está a documentação oficial para executar os testes no PHPStorm: http://devdocs.magento.com/guides/v2.0/test/unit/unit_test_execution_phpstorm.html Também há ferramentas como o VisualPHPUnit que fornece uma GUI para os testes de unidade : https://github.com/VisualPHPUnit/VisualPHPUnit

Existe alguma razão para ser tão lento? Demora ~ 7-8 minutos para analisar os arquivos de modelo. A maioria dos testes de front-end, na pior das hipóteses, leva alguns segundos; portanto, não há como obter feedback ao vivo sobre problemas.

Primeiro, o Magento 2 vem com muitos testes que definitivamente afetam o desempenho (mas é isso que é necessário para que seu código seja coberto corretamente;)). Tenho certeza de que Vinai Kopp mencionou algumas melhorias de desempenho que você pode fazer para tornar os testes mais rápidos . Espero que ele nos dê algumas idéias quando voltar das férias.

Como executar esse tipo de teste quando temos um único módulo (ou seja, tema), não toda a instância do Magento 2 (testes de CI)?

Você quer dizer executar os testes para um módulo? Sim, você definitivamente pode fazer isso, sugiro que verifique a resposta de KAndy (ele faz parte da equipe do Magento 2) : Execute testes para um módulo específico no Magento2

Parece que o PHP_CS já possui um invólucro simples para o Gulp, mas não tenho certeza de onde a configuração está armazenada. Está no arquivo /.php_cs?

Não tenho certeza de onde está esse invólucro simples. Eu não acho que é o .php_csarquivo. Pelo que sei, esse arquivo é usado apenas para as revisões estáticas de pré-confirmação do GitHub

Essas são muitas perguntas ao mesmo tempo, mas posso responder pelo menos a algumas:

1. Existe alguma razão para o M2 usar as bibliotecas de teste (PHPUnit e PHP_CS) de 2014 em vez de uma nova?

O grande desenvolvimento no Magento 2 começou por volta de 2014, então eles usaram as ferramentas disponíveis naquele momento. Quando o PHPUnit 5 foi lançado, já havia um grande número de testes que não eram compatíveis com a nova versão (veja este tópico do fórum, por exemplo), então é compreensível que eles tenham adiado uma atualização.

Presumo que os motivos para se manter uma versão antiga do PHP_CS sejam semelhantes, embora eu não tenha um exemplo concreto aqui.

2. É normal que a saída deste teste pareça uma bagunça e é difícil entender o que e onde algo errado acontece? Comparo-o com a saída de testes de qualidade de código para CSS / JS e é um pesadelo. Existe algum repórter melhor disponível ou outra maneira de obter um relatório significativo, em vez de algo parecido com um retorno do PHP?

IDEs como o PHPStorm têm boa integração com essas ferramentas, onde você pode ver os resultados do sniffer de código diretamente nos arquivos de origem e obter uma boa interface gráfica dos testes do PHPUnit também.

Além disso, o PHPUnit tem várias opções de saída. Por exemplo, com o --testdoxargumento, você obterá uma lista de verificação legível por humanos dos testes aprovados e reprovados. Ele fornece menos informações, mas uma visão geral legível. Você também pode obtê-lo no formato HTML com --testdox-html=OUTPUTFILE. Da mesma forma, você pode obter o relatório de cobertura de código em HTML com --coverage-html OUTPUTDIR.

Mas os formatos de saída mais úteis são os formatos XML e JSON que podem ser lidos por outros aplicativos como o VisualPHPUnit ou servidores de CI.

Parâmetros PHPUnit para geração de relatório:

Code Coverage Options:

  --coverage-clover <file>  Generate code coverage report in Clover XML format.
  --coverage-crap4j <file>  Generate code coverage report in Crap4J XML format.
  --coverage-html <dir>     Generate code coverage report in HTML format.
  --coverage-php <file>     Export PHP_CodeCoverage object to file.
  --coverage-text=<file>    Generate code coverage report in text format.
                            Default: Standard output.
  --coverage-xml <dir>      Generate code coverage report in PHPUnit XML format.

Logging Options:

  --log-junit <file>        Log test execution in JUnit XML format to file.
  --log-tap <file>          Log test execution in TAP format to file.
  --log-json <file>         Log test execution in JSON format.
  --testdox-html <file>     Write agile documentation in HTML format to file.
  --testdox-text <file>     Write agile documentation in Text format to file.

Mais informações: https://phpunit.de/manual/current/en/textui.html

Parâmetros PHP_CS para geração de relatório

O PHP_CS também possui diferentes formatos de relatório:

--report=xml         PHP_CS XML format
--report=checkstyle  Checkstyle XML format
--report=csv         CSV

(outros formatos: emacs, svnblame, gitblame)

Mais informações: https://github.com/squizlabs/PHP_CodeSniffer/wiki/Reporting

3. Existe alguma razão para ser tão lento? Demora ~ 7-8 minutos para analisar os arquivos de modelo. A maioria dos testes de front-end, na pior das hipóteses, leva alguns segundos; portanto, não há como obter feedback ao vivo sobre problemas.

Não sei dizer quais são as razões para o PHP_CS levar 8 minutos apenas para arquivos de modelo, mas deve ser possível para seu observador verificar apenas os arquivos alterados. A integração do PHPStorm faz isso muito bem.

4. Como executar esse tipo de teste quando temos um único módulo (ou seja, tema), não toda a instância do Magento 2 (testes de CI)?

Basta executar phpcs /path/to/themepara verificar apenas os arquivos neste diretório.

5. Parece que o PHP_CS já possui um invólucro simples para o Gulp, mas não tenho certeza de onde a configuração está armazenada. Está no arquivo /.php_cs?

Parece que esse invólucro inclui um observador de arquivos, então não vejo o benefício.

O .php_csarquivo define quais arquivos verificar e quais padrões de codificação usar. Este é um arquivo de configuração PHP_CS e independente do wrapper gulp.