¿Debería practicar TDD "mockist" o "clásica"?
mocking (5)
He leído (y releído) Las burlas de Martin Fowler no son talones . En él, define dos enfoques diferentes para TDD: "Clásico" y "Mockist" . Intenta responder a la pregunta " ¿Debería ser un clasicista o un burgués? ", Pero admite que nunca ha probado un TDD falso en "nada más que juguetes". Así que pensé que haría la pregunta aquí. Las buenas respuestas pueden repetir los argumentos de Fowler (pero con mayor claridad) o agregar argumentos en los que él no pensó o que otros han surgido desde que Fowler actualizó por última vez el ensayo en enero de 2007.
No creo que deba elegir uno sobre el otro. Ambos tienen sus ventajas y desventajas y ambos son herramientas para su caja de herramientas. El tdd "Mockist" te hace un poco más flexible en lo que puedes probar mientras que el TDD clásico hace que tus pruebas sean menos frágiles porque tienden a mirar más a la entrada / salida en lugar de mirar la implementación real. Cuando realizo las pruebas unitarias de simulacros, parece que me rompo más pruebas al cambiar la implementación.
Trato de usar el tdd clásico siempre que sea posible (aunque a menudo uso un marco de burla para configurar los stubs rápidamente). A veces noto que empiezo a hacer demasiadas pruebas al mismo tiempo o que necesito demasiados objetos para configurar una prueba. Ahí es cuando las pruebas de simulacro a menudo pueden ayudarlo a establecer pruebas más pequeñas.
Todo esto es bastante abstracto, así que espero que tenga sentido
Todavía soy relativamente nuevo en TDD, pero la forma en que me enseñaron / introdujeron las diferencias fue pensar en términos de probar la integración entre clases y no depender de datos en vivo. Por ejemplo, si tengo una clase que es bastante independiente, no depende de otras clases que he creado para un proyecto y no se envía a un entorno de datos / dev en vivo para la entrada (como un DB o una API para un sistema) entonces solo usaría pruebas clásicas de unidades en algo como NUnit o JUnit, pero cuando empiezo a probar la interacción entre clases creadas, es cuando puede ser realmente útil burlarse de otras clases personalizadas y / o interacción externa, para que puede seleccionar y probar el código de sus clases actuales sin intentar buscar un error potencial en otras clases a las que está llamando.
La pregunta sobre el tdd ficticio o clásico es sobre qué parte de la aplicación estás probando. Si tiene una arquitectura estratificada "estándar" (como DDD, por ejemplo), la capa de dominio suele ser adecuada para el tdd clásico donde prueba la unidad configurando el objeto bajo prueba, llama a algunos métodos y verifica el resultado y / o el estado.
Por otro lado, cuando está probando los servicios de aplicaciones, los controladores o la lógica de presentación que todos hacen más trabajo de coordinación, burlarse o anudar a menudo se necesitan para obtener buenas pruebas. Mi experiencia también es que estas clases tienden a llamar a otras capas (webservice, datalayer, ...) de las que realmente te quieres burlar o stub. Estas pruebas unitarias también necesitan más código de configuración, por lo que solo debes simularte cuando sea necesario.
Mi consejo es ir clásico siempre que puedas y burlarte cuando debas.
Puede considerar mirar nuestro libro, en http://www.growing-object-oriented-software.com/ . Incluye un ejemplo trabajado extendido. A medida que lo escribimos, descubrimos que la distinción estado vs. interacción es en gran medida engañosa y se trata más de un enfoque de diseño OO.
Sandi Metz expuso un enfoque muy pragmático:
Un objeto puede comunicarse con otros objetos a través de mensajes salientes o entrantes. Los mensajes pueden ser consultas (retorna algo) o comandos (ejecuta algo).
Hay cuatro combinaciones. Los mensajes de consulta salientes no deberían ser probados (ya probados como consultas entrantes de clase externa). Podría utilizar el método de prueba mockist en los mensajes de consulta salientes y la prueba clásica para el resto. Ver los enlaces
http://jnoconor.github.io/blog/2013/10/07/the-magic-tricks-of-testing-by-sandi-metz/
https://speakerdeck.com/skmetz/magic-tricks-of-testing-ancientcityruby