tutorial para logo example descargar java unit-testing junit automated-tests integration-testing

para - Enriquecimiento del informe de prueba JUnit con JavaDoc



junit logo (6)

Para un cliente, necesitamos generar informes de prueba detallados para pruebas de integración que no solo muestren que todo es verde, sino también lo que hizo la prueba. Mis colegas y yo somos vagos y no queremos piratear hojas de cálculo o documentos de texto.

Para eso, pienso en una forma de documentar las pruebas de integración más complejas con los comentarios de JavaDoc en cada método anotado @Test y en cada clase de prueba. Para los chicos de la prueba, es una buena ayuda saber a qué requisito, boleto de Jira o lo que sea que la prueba esté vinculada y lo que la prueba realmente intenta hacer. Queremos proporcionar esta información a nuestro cliente, también.

La gran pregunta ahora es: ¿cómo podemos poner el JavaDoc para cada método y cada clase de prueba en los informes JUnit? Usamos JUnit 4.9 y Maven.

Sé que hay una descripción para cada assertXXX (), pero realmente necesitaríamos una buena lista HTML como resultado o un documento PDF que enumere todas las clases y su documentación y debajo de todos los métodos @Test y su descripción, el tiempo de prueba , el resultado y si falla, la razón por la cual.

¿O hay otra alternativa para generar scripts de prueba elegantes? (¿O deberíamos comenzar un proyecto OpenSource sobre esto?? ;-))

Actualización: hice otra pregunta sobre cómo agregar un RunListener a Eclipse para que también se informe en Eclipse cuando se inició allí. La solución propuesta con un TestRunner personalizado es otra posibilidad de tener el informe de resultados de la prueba. Eche un vistazo: ¿cómo puedo usar un JUnit RunListener en Eclipse?



Como se mencionó anteriormente, maven es definitivamente el camino a seguir ... Hace la vida realmente fácil. Puedes crear un proyecto maven bastante fácil usando el plugin m2eclipse. Una vez hecho eso. Simplemente ejecute estos comandos:

cd <project_dir_where_you_have_pom_file> mvn site:site

Este comando creará las hojas de estilo para usted. En el mismo directorio ejecutado:

mvn surefire-report:report

Esto ejecutará los casos de prueba y convertirá la salida a html. Puede encontrar el resultado en ''target / site / surefire-report.html''.

A continuación se muestra el fragmento. Como puede ver, todos los casos de prueba (escritos en JUnit) se muestran en html. Otra información meta, como el número total de casos de prueba, cuántos exitosos, el tiempo empleado, etc., también están ahí.

Como no puedo cargar la imagen, no puedo mostrar la salida.

Puede ir un paso más allá y puede dar la versión exacta del complemento para usar como

mvn org.apache.maven.plugins:maven-site-plugin:3.0:site org.apache.maven.plugins:maven-surefire-report-plugin:2.10:report


Creé un programa que usa testNG e iText que genera los resultados de las pruebas en un buen informe en PDF. Puede poner una descripción de su prueba en la etiqueta @Test, y eso también se puede incluir en el informe .pdf. Proporciona los tiempos de ejecución de las pruebas y para todo el conjunto. Actualmente se está utilizando para probar webapps con selenio, pero esa parte se puede ignorar. También le permite ejecutar múltiples paquetes de prueba en una ejecución, y si las pruebas fallan, le permite volver a ejecutar solo esas pruebas sin tener que volver a ejecutar todo el paquete, y esos resultados se anexarán a los resultados originales en PDF. Vea a continuación la imagen de un enlace a la fuente si está interesado. No me importaría que esto se convierta en un proyecto de código abierto, ya que tengo un buen comienzo, aunque no estoy seguro de cómo hacerlo. Aquí hay una captura de pantalla

Así que descubrí cómo crear un proyecto en sourceforge. Aquí está el enlace sourceforge link


Tal vez vale la pena echarle un vistazo a las herramientas de "especificación ejecutable" / BDD como FIT / FitNesse, Concordion, Cucumber, JBehave, etc.

Con esta práctica tendrá la posibilidad no solo de satisfacer los requisitos del cliente formalmente, sino que también podrá llevar la transparencia a un nuevo nivel.

En pocas palabras, todas estas herramientas le permiten (o, mejor dicho, cliente) definir escenarios usando lenguaje natural o tablas, definir el enlace de construcciones de lenguaje natural a código real, y ejecutar estos escenarios y ver si tienen éxito o fallan. En realidad, tendrá una especificación "en vivo" que muestra lo que ya funciona como se espera y lo que no.

Vea una buena discusión sobre estas herramientas: ¿Cuáles son las diferencias entre los frameworks BDD para Java?


Una forma de lograr esto sería utilizar un RunListener personalizado, con la advertencia de que sería más fácil usar una anotación en lugar de javadoc. Debería tener una anotación personalizada como, por ejemplo:

@TestDoc(text="tests for XXX-342, fixes customer issue blahblah") @Test public void testForReallyBigThings() { // stuff }

RunListener escucha eventos de prueba, como inicio de prueba, fin de prueba, falla de prueba, éxito de prueba, etc.

public class RunListener { public void testRunStarted(Description description) throws Exception {} public void testRunFinished(Result result) throws Exception {} public void testStarted(Description description) throws Exception {} public void testFinished(Description description) throws Exception {} public void testFailure(Failure failure) throws Exception {} public void testAssumptionFailure(Failure failure) {} public void testIgnored(Description description) throws Exception {} }

Description contiene la lista de anotaciones aplicadas al método de prueba, por lo que utilizando el ejemplo anterior puede obtener Annotation TestDoc usando:

description.getAnnotation(TestDoc.class);

y extrae el texto como de costumbre

A continuación, puede utilizar RunListener para generar los archivos que desee, con el texto específico para esta prueba, si la prueba pasó o no, o si se ignoró, el tiempo empleado, etc. Este sería su informe personalizado.

Luego, en surefire, puede especificar un oyente personalizado, usando:

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.10</version> <configuration> <properties> <property> <name>listener</name> <value>com.mycompany.MyResultListener,com.mycompany.MyResultListener2</value> </property> </configuration> </plugin>

Esto es de Maven Surefire Plugin, Uso de JUnit, Uso de oyentes personalizados y reporteros

Esta solución tiene la desventaja de que no tiene la flexibilidad de javadoc en lo que respecta a los retornos de carro, el formato, pero tiene la ventaja de que la documentación se encuentra en un lugar específico, la anotación TestDoc.


puede usar jt-report un marco excelente para informes de prueba.