testing - serp - test seo tags
Cómo/qué burlarse en BDD (3)
Sé que una de las intenciones de Dan North al idear BDD fue alejar el vocabulario de la complejidad del dominio de prueba. Sin embargo, al implementar un enfoque de afuera hacia adentro, parece que todavía necesitamos cierta comprensión del comportamiento burlón (o comportamiento abatido, si lo prefiere). North sugiere en este video que si comienzo con los objetos de dominio más externos y avanzo hacia adentro, me burlo de los colaboradores cuando los descubro y luego los reemplazo con las implementaciones adecuadas. Así que al final, termino con un conjunto de pruebas de extremo a extremo.
Martin Fowler pareció verlo un poco diferente en esta publicación del blog cuando definió dos campos de TDD: "TDD clásico", que utiliza objetos reales cuando es posible y un simulacro cuando es necesario, y "TDD simulacro" que prefiere simulacros en la mayoría de las situaciones. Vio a la BDD como una tendencia hacia lo último. Es decir, que al final del desarrollo de una característica, el enfoque "burlón" dejaría simulacros en las pruebas reales (perdón por usar esa palabra en una discusión de BDD).
Para ser justos, ambos materiales tienen años de antigüedad, y quizás las cosas se aclararon a medida que el BDD evolucionaba a lo largo de la línea entre la aplicación a nivel de 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? North explains que la 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 iniciar sesión, no quiero tener que dar 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.
Así que parece que mi enfoque de la abstracción consistirá en que me burlo de ciertos colaboradores (o proporciono un "doble de prueba"), y algunos escenarios pueden usarlos más que otros. Por ejemplo, ¿siempre me burlo de los recursos externos, como una base de datos o un servidor de correo?
Quizás estoy haciendo la pregunta equivocada. BDD tiene que ver con la comunicación, acortar el ciclo de retroalimentación y descubrir lo que no sabes. Quizás lo que sea y lo que no sea para burlarse sea una pregunta irrelevante, siempre y cuando el comportamiento que nos interesa realmente funcione. Tengo curiosidad por los enfoques de los demás aquí.
Creo que la clave es centrarse en la B de los comportamientos de la BDD.
En este momento tiendo a ignorar los elementos de la IU y simular las capas de persistencia. Después de todos estos días, hay poca o ninguna lógica de negocios en esas capas (tendemos a enlazar los modelos de objetos directamente a la IU o DB usando preexistentes marcos muy probados).
A modo de ejemplo, en una aplicación WPF reciente (simple) que estaba construyendo: las pruebas de aceptación usan el ViewModel como el punto de entrada / exterior de la aplicación, y todo lo que se desprendía de los Repositorios de datos estaba burlado. Todas las reglas y la lógica de la aplicación existían en algún lugar entre las dos, y en realidad, esos son los comportamientos de la aplicación que debían especificarse y probarse.
Para mí, el BDD me permite verificar que he construido lo correcto. Eso significa que si conecto mi aplicación en una base de datos real y uso la IU real, debería comportarse correctamente. Ese es el fin del que estás hablando.
Ahora, si conecto mi aplicación en un almacenamiento de memoria y hablo con la aplicación a través de su nivel de API (justo debajo de la interfaz de usuario). Espero que se comporte exactamente de la misma manera.
Ahora esa es la cosa, tenemos que ser claros en lo que entendemos por comportamiento, en qué comportamiento nos interesa cuando hacemos BDD.
En mi caso, si comienzo a partir de una historia de usuario y escribo escenarios, me interesa principalmente el comportamiento que atraviesa la API de mi aplicación, la capa de servicio, las entidades de dominio, el ayudante, etc ... principalmente no me interesa mucho. En lo que sucederá en la interfaz de usuario ni en la base de datos. La verdadera carne es todo el código escrito en el lado del servidor. Ese es el comportamiento en el que estoy interesado. Si piensas así, tiene sentido deshacerte de la interfaz de usuario y el DB, porque no nos preocupamos por estos tipos. El comportamiento esperado de la interfaz de usuario es mostrar los datos que proporciona mi aplicación. La interfaz de usuario es una cosa tonta. El comportamiento esperado de la base de datos es almacenar y recuperar las entidades que mi aplicación otorga o desea. Eso también es una cosa realmente tonta. Ahora todo lo demás, ahí es donde está toda la inteligencia y soy responsable de ello.
Así que con mucho gusto ejecutaré mis escenarios BDD sin una interfaz de usuario y usando una versión en memoria de mis repositorios. El bono que obtengo de eso es realmente muy rápido, enfocado y con pruebas sostenibles.
Con respecto a la interfaz de usuario y la base de datos, escribiría pruebas unitarias de javascript para probar el comportamiento allí. Hoy en día, una interfaz de usuario puede tener mucha lógica de visualización para ocultar y mostrar cosas, pero ese tipo de comportamiento es diferente del comportamiento en mis historias de usuario bdd Escenarios (no deberían hablar de la interfaz de usuario).
Para el DB, escribiría pruebas de integración solo para comprobar que mis repositorios reales sean capaces de leer y escribir cosas en el DB.
Y finalmente, solo escribo unas cuantas pruebas de extremo a extremo para comprobar que todo está bien cuando se conectan.
Qué burlarse depende de la arquitectura. Para MVVM puedes simular el modelo para probar el modelo de vista. Para MVP puede simular la vista y / o el modelo para probar el presentador. Si desea escribir pruebas de extremo a extremo en lugar de pruebas unitarias, entonces realice la prueba a través del modelo / presentador de vista en el otro extremo de la aplicación (capa de base de datos / servicio).