Módulo 10·05·30 min

Probar excepciones y casos límite

Un buen test no solo comprueba que lo correcto funciona: comprueba que lo incorrecto falla como debe. Importes nulos, textos raros, duplicados: si el código tiene que rechazarlos, un test lo demuestra.

En Admin esProbar que la regla de validación salta con los datos malos, no solo que deja pasar los buenos

✓ En esta sub-lección

01Comprobar que un método lanza la excepción esperada con try, Assert.fail y catch.
02Probar los casos límite: null, vacío, tipos erróneos.
03Probar que un trigger rechaza un registro con addError.

La nutria: ¿Te acuerdas? · Repaso de la lección 4

¿Dónde va el Assert que comprueba el resultado de un Batch?

En el Módulo 8, el puente aprendió a rechazar: importes vacíos, textos que no son números, una segunda renovación abierta. Si mañana alguien «simplifica» parseAmount y quita el throw, ningún test de camino feliz lo notará. Hay que probar también el camino de error.

Comprobar que salta la excepción

Apex

try {
    RenewalRow.parseAmount(null);
    Assert.fail('Un importe nulo tenía que lanzar RenewalImportException');   // no debería llegar aquí
} catch (RenewalImportException e) {
    Assert.isTrue(e.getMessage().contains('vacío'), 'Mensaje inesperado: ' + e.getMessage());
}

Si parseAmount lanza, se salta al catch y se comprueba el mensaje. Si no lanza, Assert.fail hace fallar el test. Sin esa línea, el test pasaría también cuando el código no rechaza nada.

Y si tu excepción envuelve a otra, como hace parseAmount con la TypeException del texto, compruébalo también: Assert.isInstanceOfType(e.getCause(), TypeException.class, mensaje). Así nadie podrá perder la causa original sin que un test se entere.

RenewalRow.parseAmount( … )

RESULTADO

12500.00

LO PROTEGE

parsesAValidAmount()

Pasa cada entrada por parseAmount y mira qué camino toma y qué test lo protege.

Probar el rechazo de un trigger

El guardián rechaza con addError. En el test, inserta con Database.insert(registro, false) y mira el SaveResult: isSuccess() tiene que ser false y el mensaje, el de tu addError. Es el mismo SaveResult del Módulo 8, ahora del lado de quien prueba.

La nutria: ¿Y por qué no un Flow? Aquí Flow también lo intenta

Con franqueza: en un test de Flow puedes definir un registro con datos malos y comprobar el resultado, igual que harías con tu regla de validación. Lo que no puedes es probar un rechazo que dependa de otro registro, como la segunda renovación de Acme, porque sus tests no trabajan con padres ni con otros registros del objeto. En Apex preparas el escenario entero y compruebas el mensaje exacto.