2011-02-04 13 views
8

Antes de comprometer un cambio, me gustaría asegurarme de que todo ha sido probado, ya sea automáticamente o manualmente con un informe de cobertura de código, pero hay un montón de código heredado que doesn ' Tengo pruebas automáticas y no me verán afectados por mis cambios.Vinculación de la cobertura de código al control de versión

¿Hay alguna herramienta que pueda hacer una referencia cruzada entre una herramienta de control de versiones con un informe de cobertura de código y asegúrese de que todo lo que se ha modificado se haya ejecutado?

Me doy cuenta de que con la cobertura del código, esto puede dar una falsa sensación de seguridad, y con algo como esto, aún más, pero creo que valdría la pena intentarlo. Utilizo git y PHP. He utilizado la interfaz del codificador de código de XCache para explorar lo que he ejecutado, y es útil, pero sería genial si algo pudiera ejecutarse automáticamente en la confirmación de git o en el tiempo de inserción.

+0

Votando para migrar a programmers.stackexchange.com – Mchl

Respuesta

3

Para git diffs, hay una herramienta llamada diff-cover, que puede verificar la cobertura. Toma los informes de cobertura de Cobertura XML y se compara con el resultado de git diff. A continuación, informa la información de cobertura para las líneas en la diferencia.

Dado el archivo adecuado de cobertura XML, puede utilizar este comando para comprobar la cobertura de los cambios en comparación con el master rama:

$ diff-cover coverage.xml 

También es bastante simple para integrarse con un servidor CI, siempre ya que puede proporcionarle la confirmación con la que debe comparar, como $GIT_PREVIOUS_COMMIT en Jenkins.

+0

¿cómo se obtiene el formato Cobertura XML cuando se ejecutan pruebas de unidades PHP? cuando se usa esta herramienta con '--coverage-clover = coverage.xml' se equivoca con' AttributeError: 'NoneType' object no tiene el atributo 'replace'' –

3

Puede configurar un servidor de compilación continuous integration (hay muchos excellent, free build servers). Uno de los pasos de compilación sería ejecutar la cobertura de código. Puede configurarlo para ignorar el código heredado y calcular la cobertura solo para el código no heredado. Luego lo configura para que falle la construcción si la cobertura < xx%. O incluso falla si la cobertura% disminuye con respecto a la versión anterior.

+1

Buena idea; hacer un trabajo pesado como la cobertura de código en cada checkin o push hace que el control de la versión sea mucho más doloroso de usar, por lo que las personas lo odiarán. En cambio, no permita que las personas entren en la línea principal; probar las ramas de las personas en un servidor de integración continua (me gusta gitbuilder) y luego fusionar esas ramas en la línea principal solo después de que la integración continua las aprueba. – apenwarr

+1

Al volver a leer mi pregunta, la enfaticé mal. El punto no es que se ejecute en tiempo de compromiso y me impida comprometerme. El punto es que puedo estar seguro de haber corrido todo el código que he cambiado antes de enviarlo. Ser capaz de ejecutarse automáticamente en commit/push time era solo una pequeña bonificación, no el requisito real. – rjmunro

+0

@rjmunro: Sé que mi respuesta no es exactamente lo que estás pidiendo, pero creo que es lo más cerca que puedes llegar. –

Cuestiones relacionadas