Elegir nombres para las pruebas de integración

7

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

Pero con las pruebas de integración creo que sería un nombre muy largo, y ¿qué debo hacer para reemplazar 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.

    
pregunta bigstones 22.05.2012 - 14:58

4 respuestas

5

Adopto un enfoque un poco diferente con las pruebas de unidad e integración. Intento nombrarlos según las características tanto como sea posible. Luego, cuando pasan todas las pruebas, puede ver una lista de todas las funciones 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 de unidad e integración. El nombre general de la clase 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 de unidad para las correcciones de errores con un prefijo único como bugfix1002 para demostrar que el error se ha solucionado.

    
respondido por el Andrew T Finnell 22.05.2012 - 22:34
5

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

Echa un vistazo a ¡Siete Pasos !

Mi preferencia es que sea como sea que lo llame, realmente es el nombre del conjunto de pruebas (nombre del dispositivo en nuestra tarjeta), el efecto que está verificando y el mensaje de afirmación que debe destacar y hacer que la causa del error sea clara . Si encuentra que es más fácil con el nombramiento de Asherove, entonces lo apoyo sin reservas. Pero tal vez el truco sea completar la parte del "método" con cualquier cosa que haga que la condición, el resultado y la excepción tengan sentido.

Estoy contento de ver una suite llamada "MakingADeposit" con una prueba llamada "AccountDoesntExist" y un error que dice "Excepción esperada NonesuchAccount: no se recibió ninguna."

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

La tarjeta también sugiere que si no tienes un buen nombre, continúa y dale un nombre mejor cuando se te ocurra (ojalá antes de enviar el código a CI).

    
respondido por el tottinge 23.05.2012 - 00:08
1

¿Entonces el problema es que un nombre correcto de funcionalidad 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 de métodos largos (PL / SQL solo permite hasta 30 caracteres, no sé si Java y C # imponen límites de nombre tan cortos) , pero incluso si no lo hacen, se vuelven bastante difíciles de manejar más allá de cierto punto y los nombres de los métodos realmente muy largos solo podrían ser útiles para el código generado que es leído / administrado por otro código generado). Puedes intentar reducirlo a regValUnderageUnivDrvrWCovrgA_test() , pero eso 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 momento era underageUnivDrvr_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 de origen, lo que podría ser útil porque puede generar documentación de las pruebas directamente desde el código, en lugar de mapear entre la hoja de cálculo y el código.

    
respondido por el FrustratedWithFormsDesigner 22.05.2012 - 16:15
1

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

Los métodos deben probar un concepto de la característica y una gran cantidad de aserciones podrían indicar lo contrario. (Ref. "Clean Code: A Handbook of Agile Software Craftmanship" p. 132, por Robert Martin).

    
respondido por el Turnkey 22.05.2012 - 20:11

Lea otras preguntas en las etiquetas