Sé que una de las intenciones de Dan North al diseñar BDD fue alejar el vocabulario de la complejidad del dominio de prueba. Sin embargo, al implementar un enfoque de afuera a adentro, parece que todavía necesitamos cierta comprensión del comportamiento burlado (o comportamiento obstinado, si lo prefiere). North sugiere en this video que si comienzo con los objetos de dominio más externos y me abro camino hacia adentro, me burlo de los colaboradores cuando los descubro y luego los reemplazo con las implementaciones adecuadas. Entonces, al final, termino con un conjunto de pruebas de extremo a extremo.Cómo/qué burlarse en BDD
Martin Fowler parecía verlo un poco diferente en this blog post cuando definió dos campos de TDD: "TDD clásico" que usa objetos reales siempre que es posible y un simulacro cuando es necesario, y "mockist TDD" que prefiere burlarse en la mayoría de las situaciones . Él vio BDD como tendiendo hacia el último. Es decir, que al final de desarrollar una función, el enfoque "burlón" dejaría burlas en las pruebas reales (siento usar esa palabra en una discusión BDD).
Para ser justos, ambos materiales tienen años de antigüedad, y tal vez las cosas se volvieron más claras a medida que BDD evolucionó a lo largo de la línea entre la aplicación a nivel de la unidad y el nivel de aceptación.
Pero mi pregunta para la comunidad es básicamente: cuando mi historia esté completa, ¿cuánto de una prueba de extremo a extremo deberían ser mis escenarios en realidad? North explains que BDD requiere abstracciones. Por ejemplo, cuando estoy probando el comportamiento de inicio de sesión, mis escenarios detallarán lo que significa el proceso de inicio de sesión. Sin embargo, cuando estoy haciendo algún otro escenario que requiere, pero no se trata de de inicio de sesión, no quiero tener que hacer esos pasos una y otra vez. Quiero una abstracción fácil que simplemente diga "Dado que estoy conectado", así puedo ejecutar mi otro comportamiento.
Parece que mi enfoque de la abstracción se debe a que me burlo de ciertos colaboradores (o proporciono un "doble de prueba"), y algunos escenarios pueden usarlos más que otros. Por ejemplo, ¿siempre simulé recursos externos, como un DB o un servidor de correo?
Quizás estoy haciendo la pregunta incorrecta. BDD tiene que ver con la comunicación, acortando el ciclo de retroalimentación y descubriendo lo que no sabes. Tal vez qué-y-qué-no-simular es una pregunta irrelevante, siempre y cuando el comportamiento que nos interesa realmente funcione. Tengo curiosidad por los enfoques de los demás aquí.