En un proyecto que ya está funcionando y en el que por tanto no vamos a hacer TDD, el objetivo es añadir tests de integración para funcionalidades críticas y así evitar regresiones.
Idealmente es el cliente o en su defecto el Product Owner quien debe identificar dichas funcionalidades y escribir historias de usuario que el equipo de desarrollo se encargará de implementar como especificaciones ejecutables en forma de tests de integración.
Una vez identificadas y escritas las historias de usuario en formato Gherkin, debe implementarse el código que interactúa con la aplicación (Steps). Para ello podemos valernos de librerías como Cucumber o Spinach (ruby) o Behat (PHP).
Idealmente, en este último paso deberíamos seguir las prácticas recomendadas más abajo.
Estos tests simplemente deben replicar lo que el usuario haría: pinchar en enlaces y botones, rellenar formularios, etc. para después comprobar que el estado de la aplicación y de la interfaz es el que se espera.
No es un escenario ideal porque al estar ya en funcionamiento la aplicación todos los participantes en el proyecto van a estar condicionados a la hora de escribir las historias y los tests (en contraposición a TDD).
En un proyecto nuevo el objetivo es hacer TDD. Los pasos a seguir en realidad son los mismos que en un proyecto existente, con la diferencia de que los tests de integración han de estar escritos antes de hacerlos pasar.
Es un escenario ideal en el que los tests de integración son aún más si cabe especificaciones ejecutables y que además permite recopilar las historias de usuario de una forma más eficiente mediante metodologías como Event Storming.