Como sabrán Cucumber, es el framework para desarrollo en BDD, y es el actualmente uno de los más utilizados en QA, pero... ¿realmente es bien utilizado?
Cucumber tiene muchas mejoras a favor que incluyen:
Cucumber tiene muchas mejoras a favor que incluyen:
- Ser auto-explicativo
- Simple de armar
- entre otras...
Pero ... ¿podemos incluirlo en todo lo que hacemos...?
La respuesta es que en realidad depende de que se este automatizando, BDD es muy útil para automatizar la parte funcional, pero a veces se tiende a utlizarlo para automatizar procesos que en particular no cumplen con la meta precisa.
Hace tiempo leí un artículo donde trataba éste tema, principalmente me vi en casos donde se automatizan procesos de backend y a la vez en el mismo proyecto procesos de frontend (distintas interfaces, web o desktop).
En particular creo que en casos de backend, o relacionado a servicios, si se realizan pruebas como verificaciones de llamadas a APIs, lo mejor sería optar por manejarlos de forma separada:
- Cucumber >> Tests Funcionales
- RSpec >> Tests de Servicios/Backend/APIs
¿Por qué? Debido a la simplicidad de ambos.
Desde el lado funcional, si alguien intentaría leer un archivo .feature de una API, puede que resulte ser confuso, debido a que muchas veces no implica la parte funcional, y las APIs son definidas por arquitectos de software, no por analistas funcionales o de negocio.
Mientras que por otro lado, lo relacionado a la interfaz o frontend (lo que realmente ve el usuario, lo funcional) es lo que realmente concuerda mayoritariamente con Cucumber, ya que identifica que hará el sistema, y no una API.
Realmente, no es imposible tener ambos en el mismo proyecto, bajo la misma tecnología, sea Cucumber o RSpec, pero al momento de explicar o mostrar el progreso de automatización, deberíamos pensar también quién será el cliente interno que verá los casos.
Comments (0)
Publicar un comentario