NMock2.0 - cómo muñón de una llamada que no interfaz?

Question

Tengo un API de la clase que tiene cobertura de código completo y utiliza DI para burlarse de toda la lógica en la función de la clase principal (Job.Run), que hace todo el trabajo.

He encontrado un fallo en la producción donde no estábamos haciendo un poco de validación en uno de los campos de entrada de datos.

Por lo tanto, he añadido una función llamada talón de ValidateFoo () ... Escribí una unidad de prueba en contra de esta función se puede esperar un JobFailedException, corrió la prueba - no logró obviamente porque esa función estaba vacío. Añadí la lógica de validación, y ahora pasa la prueba.

Bien, ahora sabemos que los trabajos de validación. El problema es - ¿Cómo se escribe la prueba para asegurarse de que ValidateFoo () se llama en realidad el interior Job.Run ()? ValidateFoo () es un método privado de la clase de trabajo - así que no es una interfaz ...

¿Hay alguna forma de hacer esto con NMock2.0? Sé typemock soportes falsificaciones de los tipos de interfaz no. Pero cambiar libs simulados en este momento no es una opción. En este punto, si NMock no puede apoyarlo, yo simplemente añadir la llamada ValidateFoo () al método run () y prueba cosas de forma manual - que obviamente preferiría no hacerlo teniendo en cuenta mi método Job.Run () tiene 100% de cobertura en este momento. ¿Algún consejo? Muchas gracias Se aprecia.

EDIT: la otra opción que tengo en mente es crear sólo una prueba de integración para mi funcionalidad Job.Run (inyección a la misma verdaderas implementaciones de los objetos compuestos en lugar de burla). Voy a darle un valor de entrada malo para ese campo y luego validar que el trabajo ha fallado. Estos trabajos y cubre mi prueba - pero en realidad no es una prueba de unidad, sino una prueba de integración que las pruebas de una unidad de funcionalidad .... hmm ..

Edit2: ¿Hay alguna manera de hacer tihs? Alguien tiene ideas? Tal vez Typemock - o un mejor diseño

Answer 1

La versión actual de NMock2 pueden burlarse de los tipos de hormigón (no recuerdo exactamente qué versión agregado esto, pero estamos usando la versión 2.1), utilizando la sintaxis sobre todo familiar:

Job job = mockery.NewMock<Job>(MockStyle.Transparent);
Stub.On(job).Method("ValidateFoo").Will(Return.Value(true));

MockStyle.Transparent especifica que cualquier cosa que no recibo o espera debe ser manejado por la aplicación subyacente -. Para que pueda acople y crear expectativas para métodos en una instancia que está probando

Sin embargo, sólo podrá expectativas de código auxiliar y situado en métodos públicos (y propiedades), que también deben ser virtuales o abstractos. Así que para evitar depender de las pruebas de integración, tiene dos opciones:

• Hacer público Job.ValidateFoo() y virtual.
• Extraer la lógica de validación en una nueva clase e inyectar una instancia en Job.

Answer 2

Desde todas privadas todos son llamados por métodos públicos (a menos que depender de la ejecución en tiempo de ejecución reflexión), entonces esos soldados están siendo ejecutados por métodos públicos. Esos métodos privados están causando cambios en el objeto más allá de simplemente ejecutando código, como el establecimiento de campos de clase o ponga en otros objetos. Me gustaría encontrar una manera de llegar a los "resultados" de una llamada al método privado. (O burlarse de las cosas que no se deben ejecutar en los métodos privados.)

No se puede ver la clase que se está probando. Otro problema que podría estar empujando a que desea tener acceso a los métodos privados es que es una gran super clase con un bote lleno de funcionalidad privado. pueden necesitar estas clases para ser dividido en clases más pequeñas, y algunas de esas partes privadas pueden convertirse en los públicos más simples.