¿Cuál es la forma correcta de probar áreas en excepciones?

Question

Si miramos la cobertura de código de nuestras pruebas unitarias, estamos bastante altos. Pero el último% es complicado porque muchos de ellos están captando cosas como las excepciones de bases de datos, que en circunstancias normales simplemente no ocurren. Por ejemplo, el código evita que los campos sean demasiado largos, etc., por lo que las únicas excepciones posibles a la base de datos son si el DB está roto/abajo, o si el esquema se cambia bajo nuestros pies.

Entonces, ¿la única forma de simular objetos es que se puede lanzar la excepción? Eso parece un poco sin sentido. Tal vez es mejor simplemente aceptar no obtener cobertura de código 100%?

Gracias, Dan

Answer 1

Por lo general, al ejecutar excepciones de bajo nivel, como IOException o SQLException en Java, las envuelvo en una excepción que extiende RuntimeException. Siento que probar este comportamiento es bastante importante porque de lo contrario existe la muy desagradable posibilidad de tragar accidentalmente la excepción.

Por lo tanto, recomiendo probarlos, si realmente hace algo cuando se produce una excepción de bajo nivel.

Editar: Ejemplo agregado.

public void store(User user) { 
    try { 
     userDao.store(user); 
    } catch (IOException e) { 
     // Logging, perhaps some logic. 
     throw new ServiceException(e); 
    } 
} 

@Test(expected = ServiceException.class) 
public void Store_Fail() { 
    UserDao userDaoMock = createMock(UserDao.class); 
    User user = // Create test user. 
    userDaoMock.store(user); 
    replay(userDaoMock); 
    userService.store(user); 
    verify(userDaoMock); 
} 

No hay mucho para probar aquí, pero si la lógica requiere para un ServiceException a ser lanzada por qué no probarlo?

Answer 2

Una práctica común cuando un gol de cobertura del 100% se especifica es cubrir la mayor cantidad posible de código de prueba y cubrir los restantes unos porcentajes de revisión de código.

Answer 3

¿Así que la única forma de simular objetos es que se puede lanzar la excepción?

Creo que será la manera más fácil, pero también podría hacer un stub (también conocido como un objeto que amplía el objeto real, y obliga a un comportamiento como lanzar una excepción cada vez). O podría usar AOP, pero creo que usar una biblioteca como easymock o jmock va a ser la forma más fácil de hacerlo.

Eso parece un poco inútil. Tal vez es mejor simplemente aceptar no obtener cobertura de código 100%?

Cuando hablo sobre este tema, me gusta cambiar la mentalidad de las personas de preocuparse por un cierto porcentaje de cobertura, y en su lugar utilizar el porcentaje como una herramienta para que sea un mejor desarrollador. Dicho de otra manera, tener 100% de cobertura o 50% de cobertura no necesariamente significa que su código está bien escrito o incluso funcionando, pero usar Cobertura de código como indicador clave cuando está desarrollando un código sobre si ha estado haciendo pruebas, etc. una buena idea.

Mi opinión personal acerca de su pregunta es que si la aplicación es lógica, entonces vale la pena probarla. Entonces, si está atrapando y la excepción y resintonizando falsamente del método, debe tener una prueba para eso. Si está atrapando la excepción y enviándola en otra excepción, debe probar eso. Si está atrapando la excepción y no haciendo nada, entonces debería ser un olor de código que debe corregirse porque eso puede conducir a todo tipo de efectos secundarios inmanejables.

En cuanto a si el 100% no se enoja, diría que sí, no vale la pena. Debe encontrar un buen nivel de comodidad para usted (tal vez 80%, tal vez 90%) y atenerse a él. Pero no lo basaría en los tipos de pruebas (como la lógica de excepciones de prueba), solo debería basarse en la cobertura total y ser visto como un indicador de que no está escribiendo sus pruebas cuando ingresa el código.