Testes estáticos do PHP para desenvolvedores front-end


7

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?

Respostas:


2

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


Obrigado pela resposta! Comento a maioria das coisas abaixo da resposta @fschmengler, mas parece que o ponto 5. não está claro. Eu não estou perguntando sobre coisas relacionadas à implementação do Gulp, porque eu estou familiarizado com as ferramentas JS :) Eu só preciso saber como a configuração do PHP_CS é armazenada no nível do Magento.
igloczek

2

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.

  1. É 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

  1. 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.

  1. 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.

  1. 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.


Obrigado pela resposta! 1. Eu mudaria esse tópico para o segmento da proposta de melhoria, porque o b / c parece que ninguém sabe realmente o que está parando, ou seja, para atualizar o PHPUnit para a versão 4.x mais recente. 2. Eu sou um usuário Atom, b / c Eu não preciso desse recurso IDE (geralmente é inútil no front-end), portanto, estou procurando apenas melhorias no console (a saída do teste de CI também é importante) . Eu testaria esses parâmetros, mas parece que criar um módulo de impressora personalizado simples será a melhor opção. 3. Parece uma causa encontrada - os testes estáticos também executam parte dos testes de integridade e leva cerca de 4-5 minutos para terminar. 1/2
igloczek 02/09

4. Não se trata apenas de executar o PHP_CS. O teste estático contém também verificações de vulnerabilidade XXS e funções personalizadas criadas sobre o PHPUnit, portanto, provavelmente é necessário ter o pacote principal do Magento para executar qualquer coisa: <5. É um plug-in Gulp, para assistir arquivos é tratado no nível Gulp, mas não é um caso. Eu teria que saber onde Magento é armazenado configuração deste plugin (se existir, mas eu não posso imaginar um linter sem arquivo de configuração: O) 2/2
igloczek

3.-4.) De fato, há o conjunto de testes estáticos do PHPUnit que leva algum tempo, verificando dependências e outros enfeites. Descobri que você pode colocar uma lista de arquivos dev/tests/static/testsuite/Magento/Test/_files/changed_files*(pode ser gerada com get_github_changes.php) e alguns dos testes processam apenas esses arquivos. Mas, quanto ao resto, não vejo a possibilidade de restringi-los por módulo / tema. O que você pode fazer é executar um único testsuite, por exemplo, com phpunit --testsuite "Less Static Code Analysis"(veja phpunit.xml.dista lista de conjuntos de testes) 5.) sim que seria.php_cs
Fabian Schmengler

Estou pensando em extrair testes para separar o pacote do compositor e adicioná-lo como uma dependência de desenvolvimento aos nossos pacotes, para executar testes no ambiente de CI separadamente. Espero que isso vai funcionar de alguma forma: D
igloczek
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.