2012-08-02 19 views
14

¿Alguien sabe un método para generar informes de cobertura de las pruebas PHPSpec?PHPSpec y informe de cobertura

Pensé en xdebug, pero hasta donde yo sé, no puede generar informes para jenkins.

Respuesta

38

Tal como está (1.4.0) aún no es compatible con la cobertura de código. Feliz de escuchar sus comentarios sobre esto. A continuación se muestra mi opinión sobre la cobertura del código.

PHPSpec es un marco BDD. Si estuvieras haciendo BDD describirías el comportamiento de tu clase antes de escribir tu clase. Si lo hiciera de esa manera, el comportamiento relevante de sus clases estaría adecuadamente cubierto con "pruebas".

Las herramientas de cobertura de código y las métricas son útiles para el código heredado (código que escribió sin especificaciones/pruebas). Puede usar una herramienta como esta para tratar de llegar a un punto donde pueda continuar con TDD y tenga el beneficio de estar protegido de la regresión.

En general, ese enfoque no es realmente tan eficaz como la descripción del comportamiento primero (TDD). Un solo método puede ser lo suficientemente simple como para responder a más de un comportamiento requerido. Sabes que cuando estás TDDing, sigues refaccionando en el proceso, eliminando el código innecesario. Terminas con 10 especificaciones (pruebas) tocando las mismas líneas de código, todas describiendo diferentes comportamientos necesarios, todos útiles para comprender el código.

Uno de los problemas con la palabra "prueba" es que hace que las personas piensen que TDD se trata de verificación. No es. Se trata de comunicación. StoryBDD es la comunicación entre las partes interesadas y SpecBDD es la comunicación entre las clases. Simple, viviente, con suficiente documentación.

La cobertura de código hecha para garantizar que ha probado su código es una falacia, una métrica pobre en el mejor de los casos. Lamentablemente, las personas piensan que la estructura de las pruebas es más importante que las pruebas de comportamiento. Es por eso que nació BDD, para ayudar a que el enfoque vuelva al camino correcto. Asegurarse de que esta parte del código se prueba es falso porque esa parte del código puede hacer más de una cosa, debería, si está bien refactorizada. También terminará probando cosas como accesos y modificadores y constructores, etc.

Pero estoy abierto a escuchar a la comunidad sobre esto. Puedo ver dónde la cobertura de código podría ser útil. Además, dado que Sebastian Bergmann lo modificó muy bien en PHPUnit, pude reutilizarlo en PHPSpec. Preferiría que primero escribieras tus especificaciones. Obtienes cobertura de código 100% de tu comportamiento relevante de forma gratuita. En mi opinión, eso es lo que importa en su mayor parte.

+1

Su aproximación como persona más exprerienced es muy valiosa para mí.Estoy comenzando a incorporar BDD en mi equipo, es por eso que me importa mucho hacerlo bien y recopilar estadísticas útiles :) – spamec

+0

Es un gran enfoque para nuevos proyectos, pero ¿qué pasa si queremos implementar BDD en el legado existente? ¿Tienes alguna experiencia en esto? ¿Tiene sentido escribir especificaciones para el código existente? En mi opinión, para el código antiguo debería haber pruebas unitarias para nuevas especificaciones. –

+1

Gran respuesta Marcello. Aún así, la cobertura del código le da seguridad, fe donde carece :) –

6

Creo que un generador de cobertura de código sería útil para los sistemas heredados que están en proceso de ser sometidos a pruebas de estilo BDD ya que serán capaces de decir qué código no se prueba. Por mi parte, apreciaría esa característica en PHPSpec.

8

Usa Code Coverage extension to PHPSpec para generar trébol.

Si desea combinar los datos de cobertura de PHPSpec y otras herramientas (por ejemplo) PHPUnit, utilice el formato de salida PHP_CodeCoverage con la herramienta phpcov en modo fusión.

Ejemplos:

# phpspec.yml 
extensions: 
    - PhpSpec\Extension\CodeCoverageExtension 

code_coverage: 
    output: /tmp/coverage/phpspec.phpcoverage 
    format: php 

# phpunit.xml 
<logging> 
    <log type="coverage-php" target="/tmp/coverage/phpunit.phpcoverage" /> 
</logging> 

# from the command line 
phpcov merge --clover coverage.xml /tmp/coverage 

que le dará la cobertura de ambas herramientas en un formato de trébol final, como adecuados para Jenkins.

Cuestiones relacionadas