Aplicación de CQRS: ¿es necesaria la prueba de unidad de la capa de lectura delgada?

Question

Dado que algunos de los consejos para implementar CQRS recomiendan una implementación de consultas bastante cercana al metal, como las consultas de ADO.NET directamente en la base de datos (o quizás un ORM basado en LINQ), es un error intentar y unidad probarlos?

Me pregunto si es realmente necesario.

Mis pensamientos sobre el asunto:

1. La complejidad de la arquitectura adicionales para proporcionar una mockable "Thin Leer Capa" parece opuesta a la naturaleza misma de los consejos para mantener la ceremonia de arquitectura a un mínimo.
2. El número de pruebas unitarias para cubrir efectivamente cada ángulo de consulta que un usuario pueda componer es horrendo.

Específicamente estoy probando CQRS en una aplicación ASP.NET MVC y me pregunto si molestar a la unidad de prueba de mis métodos de acción de controlador, o simplemente probar el Modelo de dominio en su lugar.

Muchas gracias de antemano.

Answer 1

Tiendo a estar de acuerdo con usted en que la unidad que prueba este tipo de código no es tan beneficiosa. Pero todavía hay algún margen para algunas pruebas útiles.

Debe realizar alguna validación de los parámetros de consulta de lectura del usuario, de ser así, luego pruebe que los parámetros de solicitud no válidos arrojen una excepción adecuada, y se permiten los parámetros válidos.

Si está utilizando un ORM, considero que la relación costo/beneficio es demasiado grande para probar el código de mapeo. Suponga que su ORM ya está probado, puede haber errores en la asignación, pero pronto los encontrará y los solucionará.

También me parece útil escribir algunas pruebas de integración (utilizando el mismo marco de prueba), solo para asegurarme de que puedo establecer una conexión con la base de datos y la configuración ORM no arroja ninguna excepción de asignación. Ciertamente no desea escribir pruebas unitarias que consulten el db real.

Answer 2

La forma en que he visto algo como esta unidad probada es hacer que la unidad de prueba cree un conjunto de cosas en la base de datos, ejecute las pruebas de la unidad y luego limpie las cosas creadas.

En un trabajo anterior vi esta configuración muy bien utilizando una estructura de datos para describir los objetos y sus relaciones. Esto se ejecutó a través del ORM para crear esos objetos, con esas relaciones, los datos de eso se usaron para las consultas, y luego se utilizó el ORM para eliminar los objetos. Para hacer que las pruebas unitarias sean más fáciles de configurar, cada clase especificó valores predeterminados para usar en pruebas unitarias que no anularon esos valores. Luego, la estructura de datos en las pruebas de la unidad solo necesitaba especificar valores no predeterminados, lo que hizo que la configuración de la unidad fuera mucho más compacta.

Estas pruebas unitarias fueron muy útiles y detectaron varios errores en la interacción de la base de datos.

Answer 3

En una de mis aplicaciones asp.net mvc también he aplicado sqrc. Pero en lugar de sql y 'consultas ADO.NET' o 'Linq' usamos document database(mongodb) y cada comando o manejador de eventos base de actualización directa.

Y he creado una prueba para un controlador de comando/evento. Y después de probar el 100% de la unidad, sé que mi dominio funciona con un 95% de corrección. Pero para acciones/controladores/ui he aplicado pruebas ui (usando selenium).

Parece que ambas pruebas unitarias para el dominio (comandos/controladores de eventos y actualizaciones directas a la base de datos) y ui lo prueba sus 'pruebas de integración'.

Creo que debe probar la parte de dominio al menos, porque toda su lógica se encapsula en los controladores de comando/evento.

FYI: También comencé a desarrollar parte de dominio primero desde el marco de la entidad, que las actualizaciones directas en la base de datos a través de procedimientos almacenados, pero estaba muy contento con la base de datos de documentos. Intenté algunas bases de datos de documentos diferentes, pero mongodb parece ser el mejor para mí.

Answer 4

Como probablemente ya sepa, las pruebas unitarias tienen menos que ver con la cobertura del código y la prevención de errores que con un buen diseño. Aunque a menudo me salteo las pruebas de los manejadores de eventos del modelo de lectura cuando tengo prisa, no hay duda de que probablemente deba hacerse por todas las razones por las que el código debe ser TDD.

Tampoco he probado mis acciones HTTP (no tengo controladores en sí ya que no estoy usando Nancy .NET MVC).

Estos son puntos de integración y no suelen contener mucha lógica, ya que la mayoría están encapsulados en los manejadores de comandos y el modelo de dominio.

La razón por la que creo que es bastante fácil no probar estos es porque son muy simples y muy repetitivos, casi no hay un pensamiento profundo en la desnormalización de eventos para el modelo de lectura. Lo mismo es cierto para mis manejadores HTTP, que prácticamente solo procesan la solicitud y emiten un comando al dominio, con alguna lógica básica para devolver una respuesta al cliente.

Al desarrollar, a menudo cometo errores en este código y probablemente cometería muchos menos errores si usaba TDD, pero también tomaría mucho más tiempo y estos errores tienden a ser muy fáciles de detectar y corregir.

Mi instinto me dice que todavía debo aplicar TDD aquí, todavía está muy poco acoplado y no debería ser difícil escribir las pruebas. Si le resulta difícil escribir las pruebas que podrían indicar un olor a código en sus controladores.

Answer 5

Según mi experiencia, el 90% -99% de las lecturas que realizará si está creando un buen modelo de lectura des-normalizada DO NOT justifican que se realicen pruebas unitarias a su alrededor.

He encontrado que la forma más efectiva y eficiente para TDD una aplicación CQRS es escribir pruebas de integración que envían comandos a su dominio, luego use las consultas para recuperar los datos de la base de datos para sus afirmaciones.