java - test - JUnit 4 Expected Exception type

junit when throw exception

Question

Intento hacer una prueba de JUnit en el código que otra persona ha escrito, pero no puedo encontrar la forma de probar la excepción, porque la excepción parece carecer de un tipo.

public Pirate(String name, int initialGold) throws Exception {
if(initialGold < 0)
throw new Exception("Init Gold must be >= 0");
this.name = name;
this.numGold = initialGold;
this.health = Pirate.DEFAULT_HEALTH;
this.isCursed = false;
}

Mi fragmento de código JUnit:

@Test
public static void constructorTest() throws Exception{
rodgers = new Pirate("Dread Pirate Rodgers", 10000);
assertEquals("Dread Pirate Rodgers" , rodgers.getName());
assertEquals(10000, rodgers.getNumGold());
assertEquals(100, rodgers.getHealth());
assertEquals(false, rodgers.getIsCursed());
}
@Test()
public static void exceptionTest() throws Exception{
rodgers = new Pirate("Dread Pirate Rodgers" , -100);
}

Sé que tengo que poner expected = (algún tipo de excepción) en el paréntesis de la prueba, pero no tengo ni idea del tipo de excepción.

Answer 1

En realidad hay una alternativa a @Test(expected=Xyz.class) en JUnit 4.7 usando Rule y ExpectedException

En su caso de prueba declara una ExpectedException anotada con @Rule , y le asigna un valor predeterminado de ExpectedException.none() . Luego, en su prueba que espera una excepción, reemplaza el valor con el valor esperado real. La ventaja de esto es que sin utilizar el feo método de prueba / captura, puede especificar con mayor precisión cuál fue el mensaje dentro de la excepción.

@Rule public ExpectedException thrown= ExpectedException.none();
@Test
public void myTest() {
thrown.expect( Exception.class );
thrown.expectMessage("Init Gold must be >= 0");
rodgers = new Pirate("Dread Pirate Rodgers" , -100);
}

Usando este método, es posible que pueda probar que el mensaje en la excepción genérica sea algo específico.

ADICIÓN Otra ventaja de utilizar ExpectedException es que puede delimitar con mayor precisión la excepción en el contexto del caso de prueba. Si solo está utilizando la @Test(expected=Xyz.class) en la prueba, entonces la excepción Xyz puede arrojarse a cualquier lugar en el código de prueba, incluida cualquier configuración de prueba o pre-afirmación dentro del método de prueba. Esto lleva a un falso positivo.

Usando ExpectedException, puede diferir la especificación del thrown.expect(Xyz.class) hasta después de cualquier configuración y pre-afirmación, justo antes de invocar el método bajo prueba. Por lo tanto, se puede delimitar con mayor precisión la excepción que arrojará la invocación del método real en lugar de cualquiera de los dispositivos de prueba en sí.

JUnit 5 NOTA:

JUnit 5 ha eliminado @Test(expected=...) , @Rule y ExpectedException completo. Se reemplazan con el nuevo assertThrows() , que requiere el uso de Java 8 y la sintaxis lambda.

Answer 2

No lanzaría una Exception si el oro no es mayor o igual a cero. IllegalArgumentException una IllegalArgumentException . Ciertamente parece ilegal que tu Pirate tenga una cantidad negativa de oro.

public Pirate(String name, int initialGold) {
if(initialGold < 0)
throw new IllegalArgumentException("Init Gold must be >= 0");

Luego, en su caso de prueba JUnit, espere la IllegalArgumentException .

@Test(expected=IllegalArgumentException.class)
public static void exceptionTest() {

Answer 3

Puede usar JUnit ''expected'' para probar excepciones:

@Test(expected = ExceptionYouWishToTestFor.class)
public void divisionWithException() {
// Test Code
}

Después de eso, depende de ti lanzar esa excepción particular en tu código.

Answer 4

Puede usar la anotación esperada en @Test o proporcionar un bloque catch explícito y emitir un error si el flujo del programa no es el esperado.

@Test(expected=Exception.class) // java.lang.Exception
public static void exceptionTest() throws Exception {
rodgers = new Pirate("Dread Pirate Rodgers" , -100);
}
@Test
public static void exceptionTest() throws Exception {
try {
rodgers = new Pirate("Dread Pirate Rodgers" , -100);
fail("should not reach this");
} catch(Exception e) {
// ok
}
}

Mi preferencia personal es la primera solución.