Resuelve los problemas a los que otros ya nos hemos enfrentado en desarrollo .net
La sintaxis de RhinoMocks constraints para aplicar en Stub o Expect a veces puede resultar compleja. Su documentación es bastante completa pero en algunos casos dificil de seguir o implementar.
A continuación te dejo una breve entrada sobre cómo puedes resolver la papeleta de hacer stub sobré métodos que tienen parámetros por referencia, esto puede resultarte útil tanto para unit test de tu capa de dominio, como para flow expectation test de tu capa de servicio.
Una de mis primeras entradas al crear este blog, fue sobre una arquitectura sobre la capa de datos usando Unit Of Work, Repository Pattern y EntityFramework Code First, con el objetivo de desacoplar tu capa de datos del resto de las capas de tu aplicación donde está contenida la lógica, servicios, negocio…
Un objetivo derivado, al conseguir este desacople, es poder aplicar Mocks y Stubs sobre tu capa de datos. Mock a estas clases de unit of work y repository, haciendo stub sobre sus métodos de forma que los unit test sobre las capas superiores se mantengan siendo atómicos, independientes de la capa de datos, y por tanto mucho más rápidos que si deben acceder a estos datos. Esto por otra parte facilita una aproximación F.I.R.S.T de los unit test como menciono en otra entrada.
En anteriores entradas he presentado mecanismos para hacer Unit Test sobre métodos de lógica genéricos, que suelen ubicarse en una capa de dominio, y Flow Expectation Test sobre la capa de servicio. Ahora voy a presentarte la manera de hacer Unit Test sobre tu capa de datos.
En esta entrada presento una arquitectura que usa un patrón de diseño con Unit Of Work y Reposity Pattern. En esta otra entrada escribí sobre Rhino Mock como una de mis librerías favoritas para Unit Testing. Ahora voy a combinar ambas para hacer unit test a tus métodos de Unit Of Work, pudiendo simular una colección de datos en memoria como si de un acceso a base de datos se tratase, de forma que puedas probar tus métodos con consultas linq y testear así su resultado, siendo capaz de aproximarte cada vez al valioso TDD del que hablo en esta entrada.
En la primera entrada sobre Rhino Mocks presento una primera aproximación a los flow expectation test. En esa entrada hablo sobre validar que todas las llamadas a otros métodos son realizadas por el método que deseas probar. En ese caso se esta utilizando una misma interfaz, por lo tanto los flow expectation test son bastante sencillos. Esta situación no siempre se va a dar, tendrás muchos casos donde tus servicios llamen a métodos de distintas interfaces, y te será necesario combinar diferentes mocks para hacer este tipo de test, en esta entrada te presento como hacerlo con Rhino Mocks.
En varias de mis entradas sobre unit testing hablo sobre la potencia de esta librería de rhino mocks para hacer unit test, como en ésta sobre herramientas para unit test. Pero no solo sobre unit test debe sustentarse tu aplicación.
Hay otro tipo de test para probar el flujo de tu lógica de negocio, que son los culpables de que tome mi decisión sobre usar esta librería rhino mocks sobre otras librerías de testing. Sobre este tipo de test hablo en una entrada reciente, dando motivos para implementar este tipo de test y una arquitectura que los permita.
En esta entrada voy a entrar al detalle de como usar rhino mock para hacer diferentes flow expectation test.
En mi entrada sobre porque usar la librería Rhino Mock para unit test explico brevemente su utilidad para testear el «qué» hace un método o tu SUT (Sistem under test). A este «probar el qué» hace una función, sin entrar a los detalles técnicos sobre como cumple con su función se le puede conocer como test de flujo esperado o flow expectation test. En esta entrada te hablo sobre sus ventajas y su importancia.
Hay muchos blogs y mucha literatura que dan deficiones sobre Mocks, Stubs, Fakes, Dummies… En esta entrada voy a recurrir a las definiciones que da Martin Fowler y voy a tratar de mostrar unos ejemplos prácticos usando Rhino Mock.
El mundo del unit testing presenta una gran cantidad de librerías que puedes utilizar para abordar tus tests. Entre las mas utilizadas están las nativas de Microsoft, NUnit, Moq, Rhino Mock…
Tras haber usado en mi entorno laboral librerías nativas de Microsoft, Moq, Rhino Mock y Nunit, me he decidido por combinar estas dos ultimas con mayor frecuencia, y en esta entrada te explico por qué ha sido así.
Si ya has leído la entrada sobre ¿Qué son los Unit Test? probablemente te habrás fijado en un Data Annotation que hay sobre el método de test, llamada precisamente [Test]. En esta entrada explico su utilidad y por qué debe estar ahí, preparando nuestro framework para hacer unit test.