escritura nombres de los métodos prueba larga para describir las pruebas contra el uso de la documentación del código

Question

Para escribir las pruebas unitarias, sé que es muy popular para escribir los métodos de prueba que se parecen a

public void Can_User_Authenticate_With_Bad_Password() 
{ 
... 
} 

Si bien esto hace que sea fácil de ver lo que la prueba está probando, creo que se ve feo y no se muestra bien en la documentación generada automáticamente (como sandcastle o javadoc).

Me interesa ver qué piensa la gente sobre el uso de un esquema de nombres que es el método que se está probando y la prueba de subrayado y luego el número de prueba. Luego, utilice el documento de código XML (.net) o los comentarios de javadoc para describir lo que se está probando.

/// <summary> 
/// Tests for user authentication with a bad password. 
/// </summary> 
public void AuthenticateUser_Test1() 
{ 
... 
} 

al hacer esto me puede fácilmente grupo de mis pruebas entre sí por métodos que están poniendo a prueba, puedo ver cómo puede probar que tengo por un método dado, y todavía tengo una descripción completa de lo que está siendo probado.

tenemos algunas pruebas de regresión que se ejecutan frente a una fuente de datos (un archivo xml), y estos archivos pueden ser actualizados por alguien sin acceso al código fuente (QA monkey) y necesitan poder leer lo que está siendo probado y dónde, para actualizar las fuentes de datos.

Answer 1

¿Qué hay de cambiar

Can_User_Authenticate_With_Bad_Password 

a

AuthenticateDenieTest 
AuthenticateAcceptTest 

y traje nombre algo así como User

Answer 2

Personalmente prefiero usar los nombres largos de método. Nota También puede tener el nombre de método dentro de la expresión, como:

Can_AuthenticateUser_With_Bad_Password() 

Answer 3

prefiero la versión "nombres largos" - aunque sólo para describir lo que sucede. Si la prueba necesita una descripción de por qué ocurre, lo pondré en un comentario (con un número de error si corresponde).

Con el nombre largo, es mucho más claro lo que salió mal cuando recibe un correo (o lo que sea) que le indica qué pruebas han fallado.

lo escribiría en términos de lo que debería hacer sin embargo:

LogInSucceedsWithValidCredentials 

LogInFailsWithIncorrectPassword 

LogInFailsForUnknownUser 

no compro el argumento de que se ve mal en la documentación generada automáticamente - por qué se ejecuta JavaDoc sobre las pruebas en primer lugar? No puedo decir que alguna vez lo haya hecho, o quería documentación generada. Dado que los métodos de prueba generalmente no tienen parámetros y no devuelven nada, si el nombre del método puede describirlos razonablemente, esa es toda la información que necesita. El corredor de prueba debe ser capaz de enumerar las pruebas que ejecuta, o el IDE puede mostrarle lo que está disponible. Me parece más conveniente que navegar mediante HTML: el navegador no tiene un "Tipo de búsqueda" que me permite escribir solo las primeras letras de cada palabra del nombre, por ejemplo ...

Answer 4

Sugiero más pequeño, más clases enfocadas (prueba).

¿Por qué te gustaría hacer las pruebas de javadoc?

Answer 5

¿Muestra la documentación en el corredor de prueba? Si no, esa es una buena razón para usar nombres largos y descriptivos.

Personalmente prefiero los nombres largos y rara vez veo la necesidad de agregar comentarios a las pruebas.

Answer 6

como grupo ¿cómo nos sentimos acerca de hacer un híbrido Esquema de nomenclatura como esto

/// <summary> 
/// Tests for user authentication with a bad password. 
/// </summary> 
public void AuthenticateUser_Test1_With_Bad_Password() 
{ 
... 
} 

y obtener lo mejor de ambos.

Answer 7

He hecho mi disertación sobre un tema relacionado, así que aquí están mis centavos: cada vez que confía en la documentación para transmitir algo que no está en la firma de su método, corre el enorme riesgo de que nadie lea la documentación.

Cuando los desarrolladores buscan algo específico (por ejemplo, escaneando una larga lista de métodos en una clase para ver si lo que están buscando ya está allí), la mayoría de ellos no se molestará en leer la documentación. Quieren tratar con un tipo de información que pueden ver y comparar fácilmente (por ejemplo, nombres), en lugar de tener que comenzar a redirigir a otros materiales (por ejemplo, desplazarse el tiempo suficiente para ver los JavaDocs).

Recomiendo encarecidamente transmitir todo lo relevante en su firma.