Después de leer unos pocos artículos sobre Newable vs inyectables objetos y cómo estos conceptos se refieren a los servicios, entidades y objetos de valor de DDD, me quedé con algunas dudas sobre el uso de newables en mi código especial en mis pruebas de unidad.
Los principales candidatos para los objetos newables fueron Entidades y objetos de valor, lo que significa que, en lugar de inyectar estas dependencias en otros objetos, uno solo debería newusar una instancia de estos objetos y usarlos directamente en el código.
Sin embargo, las buenas prácticas DDD abogan por asignar responsabilidades a entidades y objetos de valor si se consideran apropiadas. Entonces, las entidades y los objetos de valor terminarán teniendo una lógica comercial seria en ellos.
Ahora, si un servicio opera en una entidad o un objeto de valor, ¿debo burlarme de la entidad u objeto de valor y pasar la simulación al servicio (la burla requerirá una interfacepara los objetos o entidades de valor que parece ser defendida)?
¿O debería simplemente newun objeto de entidad / valor y pasar una implementación concreta al servicio y violar así el principio de prueba de la unidad de probar solo una unidad?
Respuestas:
Estoy leyendo que usted es de la opinión de que las pruebas unitarias, al igual que los objetos SÓLIDOS, deben tener "una razón para romper". Es un objetivo noble, pero creo que encontrará que en muchos casos simplemente no es factible. Uno de esos casos es aquí, donde tiene un objeto de dominio "rico" (DDD diferencia entre Entidades y Objetos de valor, que comprenden el "modelo de dominio") que es una dependencia del sistema bajo prueba.
En estas situaciones, tengo la filosofía que, dadael objeto de dominio tiene su propia cobertura integral de prueba unitaria, confiando en que el objeto funcionará según lo diseñado en una prueba unitaria para un SUT diferente no necesariamente viola la prueba unitaria. Si esta prueba se rompiera debido a un cambio en el dominio, entonces esperaría que la prueba de la unidad del objeto de dominio también se rompa, lo que me lleva a algo para investigar. Si la prueba de unidad del objeto de dominio se actualizó correctamente como una prueba roja, luego se hizo verde con el cambio, y esta otra prueba falló, tampoco es necesariamente algo malo; significa que las expectativas de esta otra prueba entran en conflicto con las nuevas expectativas para el dominio, y necesito asegurarme de que ambos estén de acuerdo entre sí y con los criterios generales de aceptación del sistema.
Como tal, solo me burlaría de un objeto de dominio si dicho objeto de dominio produjera "efectos secundarios" indeseables desde una perspectiva de prueba unitaria (es decir, tocar recursos externos como almacenes de datos), o si la lógica del objeto de dominio fuera lo suficientemente compleja como para que colocarlo en el estado adecuado para la prueba se convierte en un obstáculo para definir y aprobar la prueba.
Que luego se convierte en la pregunta de conducción; cual es mas facil ¿Usar el objeto de dominio para su propósito previsto dentro de la prueba o burlarse de él? Haga lo que sea más fácil, hasta que ya no sea la opción más fácil, como cuando un cambio funcional interrumpe la prueba del servicio de una manera compleja; Si esto sucede, reescriba la prueba para producir un simulacro que exponga los requisitos funcionales de los que depende el servicio, sin la complejidad que lo rompe.
Comprenda que de cualquier manera, debe haber una prueba de integración que use el objeto de dominio real conectado al servicio real que pruebe la interacción entre estos dos en un nivel más alto de abstracción (como probar, por ejemplo, no solo la funcionalidad detrás de un servicio punto final, pero un proxy a través del cual se serializa y envía el objeto de dominio).
fuente
Confiando en la clase dependiente de que funciona correctamente, con la esperanza de que fallarán algunas pruebas unitarias cuando algo no funciona, entonces esto debería probarse muy bien . ¿Tal vez faltan algunas pruebas unitarias importantes? Puede haber un caso no probado que crearía un error, que se producirá en mi clase de prueba original y no se detectará en la clase dependiente misma.
Entonces, en mi opinión, para las pruebas unitarias, las clases dependientes deben ser burladas. Si no lo hace, entonces es una prueba de integración.
fuente