Problemas mas comunes en BDD


Siguiendo con la temática del anterior post, en esta entrada vamos a repasar algunos de los problemas más comunes que nos podemos encontrar trabajando con BDD.

Escenarios (Scenarios) que fallan en forma aleatoria u ocasional

Es cuando los Escenarios que ayer pasaban perfectamente hoy están fallando, corriendo contra el mismo código, en el mismo ambiente. Estos problemas causan que el equipo pierda confianza en las pruebas, en el código y en ellos mismos.

Lo peor de todo es intentar corregir estos escenarios, ya que cuando queremos reproducirlos para poder repararlos, dejan de fallar. Es una tarea muy dura, pero muy importante también ya que para que las pruebas automatizadas sean útiles, el equipo debe tener una confianza absoluta en sus resultados, si tenemos Escenarios que quiebren esa confianza, estamos provocando que se pierda la confianza en toda la prueba automatizada.

Para poder solucionar este problema es necesario estudiar el código y tratar de entender que puede estar pasando. Seguimos un proceso empírico donde ponemos a prueba cada una de nuestras hipótesis sobre que puede estar pasando que genera esa inestabilidad de los escenarios. En caso de quedarnos sin ideas de la raíz de este problema y no podemos reparar esos escenarios, es preferible eliminarlos antes de que sigan generando desconfianza en las pruebas automatizadas y mitigar los riesgos de que esos escenarios no tengan cobertura.

Algunas de las causas que pueden generar este problema son: Ambientes compartidos, Escenarios frágiles, Condiciones de tiempos de respuesta y espera en los pasos del escenario.

Características (Features) frágiles

Es cuando sentís que cualquier cosa que toques en los escenarios va ha provocar que el mismo falle sin una razón obvia.  Estos escenarios son fáciles de romper ya sea haciendo el más mínimo cambio en el código o cambiando datos en los mismos. Muchas veces son escenarios que se generaron con datos harcodeados o haciendo pasos que suponen pre-condiciones implícitas poco claras.

Algunas de las causas que pueden generar este problema son: Los datos utilizados por los escenarios, la duplicación de código y que se haya generado por alguien externo al equipo.

Características (Features) que tardan mucho tiempo en correr

Cada vez que se agrega un nuevo Escenario a la Característica, se esta agregando uno o mas segundos al tiempo total de la corrida de los tests. Las aplicaciones mas exitosas son aquellas que se siguen modificando y mejorando para dar un mayor beneficio al usuario final, por ende el tiempo de  corrida de las pruebas va ir siempre en aumento. Es importante no perder de vista que el objetivo de las pruebas automatizadas es tener un feedback rápido sobre el estado de la aplicación antes de introducir el código en el proceso de build y durante el mismo. Si los tests son muy lentos, nadie va a querer correrlos antes de introducir sus cambios en el servidor de integración continua y es probable que el feedback llegue tarde y solo genere que un alto porcentaje de builds fallen.

Algunas de las causas que pueden generar este problema son: Demasiados Escenarios, No planeación en cuanto el crecimiento de la cantidad de tests, Condiciones de tiempos de respuesta y espera en los pasos del escenario.

 

Has tenido o tienes alguno de estos problemas? Quieres aportar otros problemas? Deja tu comentario!!!

Te gustó el post? Quieres contribuir para que escriba más? Contribute with the Blog

 

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