La última Testing Experience tiene un interesante artículo sobre principios para tener en cuenta al momento de automatizar tests funcionales. Los quería compartir aquí ya que me parece importante tenerlos bien presentes.
1. Primero, diseñar los tests. Evitar la creación de tests on the fly. Nuestra suite de tests debe crecer orgánicamente.
2. No automatizar todo. Ciertos tests pueden ser fácilmente ejecutados en forma manual, evitando así el alto costo de automatización.
3. Escribir tests cortos. En situaciones en las que uno o más tests fallen, cualquier miembro del equipo debe ser capaz de trackear la causa del error. Es recomendable usar BDD (Behaviour-Driven Development)
4. Crear tests independientes. Evitar el acomplamiento y aumentar la cohesión de los tests.
5. Enfocarse sobre su readability. El código fuente de cada test debería estar self-documenting. Comentarios en el código deben ser evitados.
6. Tests deben ser rápidos. El testing funcional automatizado debe ser un indicador rápido de la calidad de la aplicación. Además, en un ambiente de continuous delivery, el tiempo de ejecución debe ser de unos pocos minutos.
7. Crear tests resistentes al cambio. Quizás esta es una de las principales desventajas de los tests funcionales automatizados. Los tests debería verificar sólo funcionalidad. Dependiendo del contexto también puede ser posible aplicar DDT (Data-Driven Testing)
8. Los tests automatizados no pueden reemplazar a los humanos. Este no debe ser el único testing que se ejecuta. Otras técnicas, con la intervención de los testers humanos, deben ser aplicadas sobre el software en pos de generar más conocimiento.
Germán
Es toda una problemática... bastante grande, y cada vez más requerido. Toda la práctica ágil, con la integración continua, el desarrollo incremental y muchas otras prácticas que apuntan a tener feedback de usuario final (y proveer funcionalidad entregable) lo más pronto posible, hace que sea encesario garantizar calidad cada vez más rápido. Correr muchos tests todo el tiempo, en distintos ambientes, muchas veces y muy rápido. Todo apunta a automatización.
ResponderEliminarPor otro lado, el testing (como la programación) está muchas veces en una etapa artesanal, fuertemente dependiente de ejecución manual y supervisada.
¡Gracias Carlos por el comentario! Creo que el desafío está en definir hasta dónde es posible y estamos dispuestos a automatizar (pensando en el costo/beneficio)
Eliminar