Cómo evitar el código duplicado al usar mocks en unittest

Question

Estoy usando la inyección de dependencia para proporcionar simulaciones de código fuera de mi clase bajo prueba. Me encuentro escribiendo mucho del mismo código una y otra vez, ya que necesito burlar AuthProvider, ConfigurationManager, etc. que se usan en el método que quiero probar. El método contiene ramas (if-then-else) y, por lo tanto, tengo varias pruebas para probar todas las rutas de ejecución del método. Estoy instanciando cada uno de los simulacros varias veces (una vez en cada método de prueba), pero me pregunto si esta es la forma incorrecta. También estoy poniendo expectativas para los simulacros y las respuestas preestablecidas que evidentemente son principalmente de copiar y pegar, ya que las llamadas a AuthProvider.Authenticate() se invocan en todos los métodos

En cada método configuro un repositorio simulado y al fin de cada método, verifico el repositorio simulado. ¿Debo tener algún tipo de fábrica para crear estos simulacros junto con establecer sus expectativas y valores de retorno y, en caso afirmativo, cómo?

Para la implementación de simulaciones estoy utilizando RhinoMocks.

Answer 1

"instanciar cada uno de los simulacros varias veces" no es un problema. Los objetos son gratis.

Solo asegúrese de no definir las clases simuladas en numerosas ocasiones. Las clases son caras

Además, tiene un método "setUp" en un TestCase que le permite crear un dispositivo que se utiliza en todas las pruebas. Sí, es reconstruido para cada prueba. No, eso no es un problema a menos que sea dolorosamente lento.

Answer 2

Es posible que desee utilizar el estilo de prueba AAA para que tenga varias pruebas con una configuración común. Here's a decent example.

Answer 3

Aquí está mi ..

yo no usaría simulacro en el caso ... Me gustaría utilizar un método de fábrica para devolver una aplicación falsa de la clase y el uso de la inyección de dependencias para utilizar esta aplicación en su lugar. De esta forma evitaría la duplicación y podría reutilizar esta implementación de nuevo ... otra vez esta implementación de fábrica necesita ser refactorizada apropiadamente, es decir, sin duplicación.

Se burla, supongo que debería usarse cuando está probando alguna dinámica comportamiento ... algo así como ... se llamó un método en el subsistema cuando realicé alguna acción en SUT ... y más tarde en la llamada verify() para verificar este comportamiento ... también hay un buen artículo sobre Martin Folwer bliki Mock Aren't Stubs

Answer 4

Los marcos de grabación y reproducción como EasyMock fallan si no establece una expectativa sobre una llamada simulada. Pero los frameworks como Mockito simplemente graban todas las llamadas y te permiten verificar solo las que importan. Por lo tanto, no tiene que establecer expectativas en todos los métodos en todas las pruebas.

Y volviendo a su problema de instanciar Mocks en cada método de prueba, hay una manera mejor que usar el método setUp(). Mockito proporciona una anotación @Mock. Entonces usted declara sus variables (como campos) como: @Mock Repository repositoryMock

y simplemente llame a initMocks() en setUp(). Todos los objetos simulados declarados están automáticamente disponibles en sus pruebas sin crear explícitamente Mocks.

Answer 5

Suponiendo que está utilizando NUnit, puede usar variables de instancia para sus Mocks y restablecerlos en Configuración/Desarmado. Si ve patrones repetidos, haga lo que hace con el código de producción: refactorice y extraiga métodos auxiliares que expresen lo que intenta lograr (si no hay nada en común, entonces hay un problema con el diseño del código de producción).

Si hay divisiones significativas en la configuración, considere escribir más de una clase de prueba para su clase de producción.

Finalmente, piense si su clase de producción está demasiado ocupada y parte del comportamiento debe extraerse en un objeto auxiliar.

¡Escucha las pruebas!