18
Según el título, me pregunto si hay un mecanismo con easymock para probar si un método no se llamó durante su vida útil.EasyMock: prueba ese método en el simulacro no se llama
A
Respuesta
11
De manera predeterminada, Easymock lanzará una excepción para los métodos que se invoquen y para los que no se establecieron expectativas explícitamente.
14
Desde el EasyMock documentation:
Niza Mocks
en un objeto devuelto por Mock maqueta() el comportamiento por defecto para todos los métodos consiste en lanzar una AssertionError para todas las llamadas de método inesperadas. Si desea un objeto simulado "agradable" que de forma predeterminada permita todas las llamadas al método y devuelva valores vacíos apropiados (0, nulo o falso), utilice niceMock() en su lugar.
Entonces, lo que está preguntando es el comportamiento predeterminado.
14
Sé que esta pregunta es muy antigua pero tuve la misma pregunta que el OP y eché un vistazo más. Encontré la siguiente solución:
Al agregar .andThrow(new AssertionFailedError()).anyTimes(); al final de su declaración de EasyMock, la prueba fallará cuando se llame al método simulado.
La razón por la cual esto es mejor que simplemente no usar NiceMock y dejar que la prueba falle debido a la llamada al método no bloqueado es porque esto permite probar específicamente que el método XYZ no fue llamado en el escenario dado.
Me gustaría dar crédito a David Wallace por esta respuesta. Encontré esta solución en su respuesta en la siguiente publicación: Test that void method didn't get called with EasyMock
+2
Creo que esta debería ser la respuesta aceptada. La razón es que las pruebas unitarias a menudo se cambian con nuevos requisitos y es muy fácil pasar por alto por qué no se estableció una expectativa falsa. Esta solución hace explícita la llamada al método que falta, por lo que exige más atención de la persona que cambia el código. – mindreader
Cuestiones relacionadas
- 1. EasyMock: burló objeto se llama método real
- 2. Cómo verificar si se llama al método en el sistema bajo prueba (no es un simulacro)
- 3. Prueba Excepciones de un método con EasyMock
- 4. ¿Cómo se llama un simulacro 'manual'?
- 5. Comprobar que el método de simulacro se llama sin ningún tipo de parámetros pasados (en PHPUnit)
- 6. Prueba de que el método vacío no se llamó con EasyMock
- 7. El método Objective-C no se llama
- 8. Cómo inyectar el simulacro de EasyMock en el campo privado de la clase probada
- 9. El método "clickedButtonAtIndex:" delegado no se llama
- 10. EasyMock 3.0, clase burla lanza java.lang.IllegalStateException: no última llamada en un simulacro disponibles
- 11. ¿Cómo verificar que NO se invocó ese método en Moq?
- 12. Método virtual que no se llama
- 13. WebView: WebViewClient.onPageStarted método no se llama
- 14. cómo crear un simulacro en un caso de prueba modelo
- 15. método acelerómetro delegado no se llama
- 16. JUnit EasyMock llamada al método inesperado
- 17. Establecer expectativas negativas en EasyMock
- 18. Moq Setup no funciona, el método original todavía se llama
- 19. El método de inicio del iPhone UIViewController no se llama
- 20. El método getView() de ArrayAdapter no se llama
- 21. El método JSF 2.1 ViewScopedBean @PreDestroy no se llama
- 22. ¿Cuándo se llama el método layoutSubviews?
- 23. NSFilePresenter -presentedSubitemDidAppearAtURL: el método nunca se llama
- 24. Se burló de método privado con PowerMock, pero el método subyacente todavía se llama
- 25. Animación de UIView didEndSelector: ¿el método no se llama?
- 26. ¿cuándo se llama el método dealloc?
- 27. NSTimer no llama al método
- 28. mouseMoved no se llama
- 29. C#: ¿Cómo se prueba el método IEnumerable.GetEnumerator()?
- 30. método no se llama cuando se utiliza yield return
Me resulta molesto el comportamiento predeterminado, ya que muy fácilmente se termina "requiriendo" en la prueba que el código que se prueba es ineficaz. Una vez hice un refactor simple de mover una llamada a getSomething() fuera de un bucle, lo que causó que la prueba fallara porque no llamé getSomething 40 veces (!), Y los simulacros "no agradables" fomentan este tipo de prueba (ya que fallaría si esperaba solo una llamada antes de la refactorización). –
@Stein: de acuerdo. Las pruebas unitarias deben ser de grano fino, idealmente probar solo una cosa. burlas "no agradables" desalientan esto. –
Por mi lectura de la pregunta, el OP quiere un simulacro que fallará la verificación si se llama. Los buenos simulacros no son lo que el OP quiere porque cuando se llama a un buen simulacro durante la prueba, todavía pasa la verificación. –