¿Es una buena práctica poner los comentarios de Javadoc en las clases y métodos de prueba junit? ¿O es la idea de que deberían ser tan fáciles de leer y simples que no es necesario proporcionar una descripción del intento de la prueba?Javadoc en las clases de prueba de Junit?
Personalmente uso los comentarios de javadoc con moderación ya que creo que aumentan el desorden en la pantalla. Si puedo nombrar una clase, función o variable de una manera más autodescriptiva, prefiero un comentario. Un excelente libro para leer sobre este tema es Clean Code por Robert C. Martin (a.k. un tío Bob).
Mi preferencia personal es hacer que tanto la clase y métodos de auto descriptivos decir
class ANewEventManager {
@Test
public void shouldAllowClassesToSubscribeToEvents() {
/* Test logic here */
}
}
Una ventaja de este enfoque es que es fácil de ver en la salida junit lo que está fallando antes de navegar por el código.
Uso Javadoc en mi prueba mucho. Pero solo se vuelve realmente útil cuando agrega su propia etiqueta a su javadoc.
El objetivo principal aquí es hacer que la prueba sea comprensible para otros desarrolladores que contribuyan a su proyecto. Y para eso ni siquiera necesitamos generar el javadoc real.
/**
* Create a valid account.
* @result Account will be persisted without any errors,
* and Account.getId() will no longer be <code>null</code>
*/
@Test
public void createValidAccount() {
accountService.create(account);
assertNotNull(account.getId());
}
A continuación, tendremos que notificar a nuestro plugin Javadoc en maven que hemos agregado una nueva etiqueta.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.8</version>
<configuration>
<tags>
<tag>
<name>result</name>
<placement>a</placement>
<head>Test assertion :</head>
</tag>
</tags>
</configuration>
</plugin>
</plugins>
</build>
Y ahora todo lo que queda por hacer es llamar a nuestro plugin maven.
javadoc:test-javadoc (or javadoc:test-aggregate for multi-module projects)
Este es un ejemplo bastante fácil, pero cuando se ejecutan pruebas más complejas, es imposible describir las pruebas por el simple uso de un nombre de método de auto-descriptivo.
¿Cuál sería el resultado de tu ejemplo? – jgomo3
También me gustan los comentarios en UT, ayuda a entender el caso de uso en segundos.
Creé una pequeña biblioteca para incluir descripciones en la pila de cualquier tipo de informe, cualquiera que esté revisando los informes puede acceder fácilmente al problema.
El nombre de la biblioteca es Frutilla, no dude en usarlo https://github.com/ignaciotcrespo/frutilla
lectura código limpio en este momento. Acabo de terminar Unit Testing por Roy Ohserov quien realmente enfatizó la legibilidad humana de las pruebas de unidad e integración. – HDave