Cuándo esperar y cuándo stub?

Question

Yo uso NMock2, y he redactado las siguientes clases NMock para representar algunos conceptos marco simulacros comunes:

• Expect: esto especifica qué método debe devolver burlado y dice que debe producirse la llamada o la prueba falla (cuando se acompaña de una llamada a VerifyAllExpectationsHaveBeenMet())

.

• Stub: esto especifica qué método debe devolver burlado, pero no puede causar un error de la prueba

.

Entonces, ¿qué debería hacer cuando?

Answer 1

Una gran cantidad de marcos burlones están trayendo los conceptos de burla y talones de más cerca y más cerca al punto de que pueden ser considerados funcionalmente casi lo mismo. Desde un punto de vista conceptual, sin embargo, por lo general tratan de seguir esta convención:

• Mock . Sólo cuando se está tratando de forma explícita para verificar el comportamiento del objeto bajo prueba (es decir, la prueba está diciendo que este objeto debe llamar a ese objeto)
• Trozo : Cuando usted está tratando de probar algunas funciones / comportamiento, pero con el fin de conseguir que el trabajo se debe confiar en algunos de los objetos externos (es decir, la prueba está diciendo que este objeto debe hacer algo , pero como un efecto secundario, puede llamar a ese objeto)

Esto se vuelve más clara cuando se asegura de que cada una de sus pruebas de unidad única prueba una cosa. Claro que si usted intenta probar todo en una prueba a continuación, que también podría esperar todo. Sin embargo, sólo esperando que las cosas prueba de unidad específica está comprobando, su código es mucho más clara, porque se puede ver de un vistazo lo que el objetivo de la prueba es.

Otra ventaja de esto es que usted va a ser un poco más aislado de cambio y obtener mejores mensajes de error cuando un cambio provoca una ruptura. En otras palabras, si el cambio subtley alguna parte de su aplicación, su más probable conseguir de fractura de una sola prueba, que le mostrará exactamente lo que está roto, en lugar de todo un conjunto de pruebas que se rompen y sólo la creación de ruido.

Editar : Podría ser más clara en base a un ejemplo artificial donde un auditorías objeto calculadora todas las adiciones a una base de datos (en pseudo-código) ...

public void CalculateShouldAddTwoNumbersCorrectly() {
    var auditDB = //Get mock object of Audit DB
    //Stub out the audit functionality...
    var calculator = new Calculator(auditDB);
    int result = calculator.Add(1, 2);
    //assert that result is 3
}

public void CalculateShouldAuditAddsToTheDatabase() {
    var auditDB = //Get mock object of Audit DB
    //Expect the audit functionality...
    var calculator = new Calculator(auditDB);
    int result = calculator.Add(1, 2);
    //verify that the audit was performed.
}

Así que en el primer caso de prueba que estamos probando la funcionalidad del método Add y no les importa si se produce un evento de auditoría o no, pero sucede que saber que la calculadora no funcionará con una referencia a cabo de manera AUDITDB acabamos de stub hacia fuera para darnos el mínimo de funcionalidad para conseguir nuestro caso de prueba específica de trabajo. En la segunda prueba que estamos probando específicamente que cuando se hace una Add, el evento de auditoría que pase, por lo que aquí usamos expectativas (aviso que ni siquiera me importa lo que el resultado es, ya que eso no es lo que estamos probando).

Si usted podría combinar los dos casos en una sola, y hacer valer las expectativas y que su resultado es 3, pero luego se está probando dos casos en una unidad de prueba. Esto haría que sus pruebas más frágil (ya que hay una mayor superficie de las cosas que podrían cambiar para romper la prueba) y menos clara (ya que cuando la prueba combinada falla que no es inmediatamente obvio cuál es el problema .. es la adición no está funcionando, o se la auditoría no funciona?)

Answer 2

"Hay que esperar acciones, consultas stub". Si la llamada se debe cambiar el estado del mundo fuera del objeto bajo prueba, a continuación, hacer que sea una expectativa - usted se preocupa por la forma en que se llama a. Si es sólo una consulta, se le puede llamar una vez o seis veces sin cambiar el estado del sistema, a continuación, derivadas La llamada.

Una cosa más, se dio cuenta de que la distinción es entre los talones y las expectativas, es decir las llamadas individuales, no necesariamente objetos enteros.

Answer 3

Bueno ... en mi humilde opinión no puede ser más simple: si la prueba se trata de garantizar su presentador llamar a guardar, siga un esperar. si la prueba se trata de garantizar el presentador se encargará de excepción con gracia si Guardar vomita, hacer un trozo.

Para más detalles, echa un vistazo a este podcast por Hanselman y Osherove (autor de el arte de las pruebas unitarias)