Continuando con el tema pruebas, es hora de hablar de las pruebas no-unitarias.
Pruebas de integración de componentes
Estas pruebas buscan probar componentes en forma NO aislada. Pero no son necesariamente pruebas de usuario. Hay ciertos casos donde es muy costoso aislar un componente para su prueba o que incluso, puede que no tengas sentido ese aislamiento pues la parte crítica radica justamente en la integración.
Pruebas de aceptación funcionales (o aceptación de stories)
Son las pruebas que definirán si hemos completado o no una story dada. Son naturalmente pruebas de integración, ya que no prueban un componente aislado sino también la interacción de varios componentes (son no-unitarias).
Estas pruebas sí son de la incumbencia del usuario, por eso es que intentamos hacerlas con alguna herramienta que le resulte cómoda al usuario (que en general no es una persona técnica).
En nuestro caso usaremos Cucumber. Cuando hacemos BDD estamos haciendo este tipo de pruebas.
Nuestro foco con estas pruebas es asegurarnos que entendimos bien la story y que el código que escribimos hace lo que tiene que hacer. Como consecuencia de esto no debería ser relevante donde ejecuto las pruebas. O sea, no es necesario instalar la aplicación en un ambiente particular para ejecutar estas pruebas. Al mismo tiempo, podría en algunos casos escribir steps de cucumber que manipulen directamente los objetos de mi modelo.
Pruebas de aceptación del sistema
Estas pruebas son similares a la anteriores, pero adicionalmente también queremos asegurarnos que la aplicación fue correctamente configurada y que todo su ecosistema está perfectamente funcional. Esto implica que sí es relevante el lugar donde pruebo la aplicación. Debería ser un ambiente similar al de producción.
Aquí ya no estamos hablando de hacer BDD. Respecto de las herramientas, puedo usar un robot tipo Selenium o VSTest o incluso Rspec. Es más, mucha gente hace estas pruebas en forma manual.
También puedo utilizar cucumber, pero con algunas restricciones:
- Seguramente me interese utilizar un driver de cucumber que levante el navegador
- No podré manipular objetos del modelo en mis steps de cucumber.
Muchas veces estas pruebas se hacen en forma manual. El equipo termina el desarrollo, instala la app en un ambiente de test y un equipo de testers ejecutar pruebas a modo «caja» negra.
Continuará….
Muy bueno Nico. Un tema que me surge a partir de esta lectura y otras es que a veces, las pruebas de integración de componentes pueden ser mejor que las unitarias porque el contexto de integración, con ejemplos reales representativos para el negocio, se describe bien para la prueba unitaria pero pierde claridad cuando se fragmenta para probar las interfaces más chicas de los componentes individuales.
Quise decir «se describe bien para la prueba de integración»
Coincido, gracias por el aporte.