Prefijo para los métodos de prueba en la Unidad: "prueba" vs "debería"

Question

Es una práctica común para los nombres de los métodos de prueba en JUnit con "prueba". Pero en los últimos años, algunas personas cambiaron esto al prefijo "debería".

Si quiero probar la creación del cliente en una base de datos, normalmente nombraría el método "testCustomerCreation". Sin embargo, algunas personas llamarían "shouldCreateCustomer".

Esto es un gusto personal cuando soy la única persona en el proyecto o cuando todos los demás en el proyecto están de acuerdo conmigo. Pero cuando/donde este no es el caso, comienzan a aparecer algunas divergencias o mezclas inconsistentes.

Leí en alguna parte un artículo de un tipo que llamó a sus métodos como "testShouldCreateCustomer", y por esta razón decidió soltar el prefijo "prueba". Pero, de hecho, no estaba prefijando con "prueba", estaba usando "testShould" y cambió a "should". Obviamente, esto no me convenció.

Personalmente estoy muy inclinado a adherirme al prefijo "prueba" porque los nombres de los métodos normalmente comienzan con verbos en forma de infinitivo ("obtener", "establecer", "agregar", "eliminar", "borrar", " enviar "," recibir "," abrir "," cerrar "," leer "," escribir "," crear "," enumerar "," explotar "," imprimir ", etc., por lo que es" prueba "). Entonces, prefijar el nombre de un método con "debería" hace que suene realmente muy extraño para mí, se ve mal.

Entonces, ¿cuál es la verdadera razón para usar "debería" en lugar de "probar"? ¿Cuáles son las grandes ventajas y desventajas?

Answer 1

La convención 'Should' está alineada con el estilo de prueba behaviour driven development.

yo personalmente prefiero realmente escribir pruebas en este estilo, ya que le anima a escribir pruebas que leen como especificaciones, y más en línea con el comportamiento de la clase o del sistema que se está probando.

Siempre que sea posible, a veces voy un paso más allá y dar la clase de prueba aún más contexto utilizando su nombre:

class ANewlyCreatedAccount { 
    shouldHaveAZeroBalance() {} 
    shouldCalculateItsOwnInterest() {} 
} 

Al nombrar a sus clases y pensando en ellos en este estilo de especificación, esto le puede dar una mucha guía en que prueba escribir, y en cuyo orden debe escribir las pruebas y hacerlas verdes.

Sí, 'should' vs 'test' es solo un prefijo y es importante ser consistente, pero esta pregunta también es sobre el estilo y la mentalidad de cómo probar el código y elegir qué pruebas escribir. BDD tiene un montón de valor, así que sugiero leer más y probarlo.

Answer 2

La consistencia es más importante que la correcta en la nomenclatura. Si hay alguna pregunta sobre un proyecto, el miembro técnico responsable del proyecto debe describir las prácticas de codificación formalmente para que problemas como este no destruyan el valioso tiempo del proyecto.

Answer 3

En el JUnit original, los métodos de prueba tenían que comenzar test. Muchos marcos para otros idiomas copiaron esta convención. A pesar de que ya no es el caso en JUnit, y aunque otros marcos pueden ser diferentes, creo que la mayoría de los programadores todavía están bastante familiarizados con los métodos nombrados, por ejemplo. testX como pruebas unitarias, por lo que creo que es bueno apegarse a la convención test por ese motivo.

Answer 4

Diría que el prefijo 'prueba' es simplemente un remanente de los días de preanotación cuando era necesario. Sugeriría que simplemente use nombres significativos para sus casos de prueba (y eso puede significar con o sin 'prueba').

Prefiero ponerle nombre al método de prueba para que quede claro lo que se está probando. es decir,

checkNullParameter() 
runSimpleQuery() 
runQueryWithBadParam() 

Todos los casos de prueba se encuentran en un directorio de prueba de todos modos y todas las pruebas reales se anotan, por lo que el prefijo 'prueba' es bastante redundante.

Answer 5

Prefiero el sufijo test. Es posible que tenga un método con un prefijo should en su proyecto, p. shouldBuy y su prueba se llamaría testShouldBuy porque shouldShouldBuy se vería muy extraño.

También uso el MoreUnit plugin para Eclipse, que crea automáticamente un método de prueba con el prefijo test cuando pulso Ctrl+U o saltar al método de ensayo cuando pulso Ctrl+J. (Aunque puede configurar el prefijo que usa.) Si no es coherente con su nombre, las herramientas automatizadas como MoreUnit no podrán ayudarlo con sus pruebas.