Sobre las pruebas de integración

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.

Un caso donde estas pruebas tiene sentido es cuando tengo que testar la funcionalidad de búsqueda de mi capa de acceso a datos. Si bien puede que tenga un ORM, puntualmente para las cuestiones de búsqueda “avanza” puede que el ORM termine bastante acoplado a la base.
Estas pruebas también suelen usarse para testear la aplicación desde los controller hasta la base, pasando por alto las vistas (que suelen ser muy frágiles/cambiantes/difíciles de testear)
Estas pruebas suelen codearse usando una herramienta de prueba unitaria, aunque conceptualmente no son unitarias.

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  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á….

4 comentarios en “Sobre las pruebas de integración

  1. 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.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s