Elegir nombres para pruebas de integración

Con las pruebas unitarias, el dominio es bastante pequeño, por lo que es fácil. Usé el methodName_conditions_result()esquema de Osherove y lo encontré muy claro.

Pero con las pruebas de integración siento que sería un nombre muy largo, y ¿qué pongo en lugar de methodName? ¿Cómo nombro las clases de prueba de integración?

Los ejemplos del mundo real de nombres de pruebas de integración son muy bienvenidos. Espero que las respuestas también me ayuden a comprender mejor estas pruebas.

Tomo un enfoque un poco diferente con las pruebas unitarias y de integración. Intento nombrarlos en función de las características tanto como sea posible. Luego, cuando pasan todas las pruebas, puede ver una lista de todas las características que funcionan y no funcionan.

• canRegisterUser
• canHandleInvalidInput
• canRelayDocumentBetweenServers
• canCreateSchema
• canLoginUsingWebService
• canLoginUsingBasicAuth
• canDeleteDocument
• canAddDocument

No siempre es pragmático nombrar las pruebas de esta manera, pero puede ser muy útil, especialmente después de leer cientos de pruebas unitarias y de integración. El nombre de clase global que contiene estos métodos también debe ser indicativo de las características que se están probando. Ayudará con la organización.

También sugeriría nombrar cualquier prueba unitaria para la corrección de errores con un prefijo único como bugfix1002para demostrar que el error se ha solucionado.

Esto realmente se escribió para ayudar con las pruebas unitarias, pero quizás descubra que se aplican las mismas reglas (más o menos) a las pruebas de integración:

¡Mira los Siete Pasos !

Prefiero que sea como lo llames, es realmente el nombre del conjunto de pruebas (nombre del dispositivo en nuestra tarjeta), el efecto que estás comprobando y el mensaje de afirmación que debe destacarse y aclarar la causa del error. Si descubres que es más fácil con el nombramiento de Asherove, entonces lo apoyo de todo corazón. Pero tal vez el truco es completar la parte del "método" con lo que sea que tenga sentido la condición, el resultado y la excepción.

Estoy feliz de ver una suite llamada "MakingADeposit" con una prueba llamada "AccountDoesntExist" y un error que dice "Excepción esperada de NonesuchAccount - ninguna recibida".

Alternativamente, si no le importa que separe el nombre del conjunto de pruebas con "::", estoy de acuerdo con "AccountHandling :: MakingADeposit_AccountDoesntExist_ThrowsAnException"

La tarjeta también sugiere que si no tiene un buen nombre, continúe y proporcione un nombre mejor cuando se le ocurra (con suerte antes de enviar el código a CI).

Las pruebas de integración deben seguir algunas reglas similares a las pruebas unitarias en el sentido de que cada prueba debe probar un aspecto de un requisito pero prueba el sistema en su conjunto. La clase debe nombrar todo lo que se está probando, por ejemplo, "TpcInputValidation" y la denominación del método debe reflejar expresamente lo que la prueba está tratando de hacer sin ser demasiado prolijo, por ejemplo, "shouldRaiseValidationErrorWithBadDates ()".

Los métodos deberían probar un concepto de la característica y una gran cantidad de afirmaciones podrían indicar lo contrario. (Ref. "Código limpio: un manual de artesanía de software ágil" p. 132, por Robert Martin).

Entonces, ¿el problema es que un nombre de funcionalidad adecuado es demasiado largo para un nombre de método? Sé que es incómodo comenzar a escribir métodos de prueba con nombres como registerAndValidateUnderageUniversityDriverWithCoverageSetA_test()y podría romper las reglas del compilador para nombres largos de métodos (PL / SQL solo permite hasta 30 caracteres; no sé si Java y C # imponen límites de nombres cortos, pero incluso si no lo hacen, se vuelve bastante difícil de manejar después de cierto punto y los nombres de métodos realmente muy largos solo pueden ser útiles para el código generado que es leído / administrado por otro código generado). Puedes intentar acortarlo, regValUnderageUnivDrvrWCovrgA_test()pero también es realmente horrible de leer. Una opción que utilicé y que no me gustó, pero que era la mejor opción en ese momentounderageUnivDrvr_test_01()y luego había una hoja de cálculo que asignaba los nombres de los métodos a una descripción mucho más larga de la funcionalidad que se estaba probando. Feo, pero funcionó. También puede documentar la descripción de la prueba en la documentación de la función en el archivo fuente, lo que podría ser útil porque puede generar documentación de las pruebas directamente desde el código, en lugar de mapear de un lado a otro entre la hoja de cálculo y el código.