Apex Academy
Módulo 10·03·25 min

Assert: verificar de verdad

La cobertura dice qué líneas se ejecutaron; el Assert dice si hicieron lo correcto. Un test sin Assert pasa aunque el código esté mal. Hoy aprendes a escribir comprobaciones que fallan cuando deben.

En Admin esEl «resultado esperado» de un caso de prueba de UAT

✓ En esta sub-lección

  1. 01Usar los métodos de la clase Assert para comprobar resultados.
  2. 02Escribir mensajes que expliquen qué falló.
  3. 03Reconocer un test que da cobertura pero no comprueba nada.

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

El test A cambia un registro del setup. ¿Lo ve cambiado el test B?

Un compañero dice que AsyncContext, la clase de la tarea 1 del Módulo 9, ya está probada: su test da 100 % de cobertura. Lo abres y encuentras que llama a los dos métodos y termina con Assert.isTrue(true). Ese test pasaría aunque isAsync() devolviera siempre true. Cubre, pero no prueba.

Preparar, actuar, comprobar

Apex
@isTest
static void describesTheSynchronousBudget() {
    // 1 · Preparar: aquí no hace falta nada (lección 2 si hicieran falta datos)
    // 2 · Actuar: una sola llamada, la que se prueba
    String text = AsyncContext.describe();
    // 3 · Comprobar: lo esperado, lo obtenido y qué significa si no coinciden
    Assert.areEqual('síncrono · 100 consultas · 10000 ms de CPU', text,
        'La descripción síncrona no coincide');
}
MétodoFalla si…
Assert.areEqual(esperado, real, msg)los dos valores son distintos
Assert.areNotEqual(a, b, msg)son iguales
Assert.isTrue(cond, msg) / isFalsela condición no es la esperada
Assert.isNull(x, msg) / isNotNullel valor es (o no es) null
Assert.fail(msg)se llega a esa línea (lección 5)

El mensaje es opcional, pero es lo primero que leerás cuando el test falle dentro de seis meses, en un despliegue que no es el tuyo. «La descripción síncrona no coincide» te dice dónde mirar; sin mensaje solo verías los dos valores. Y en código antiguo verás System.assertEquals: es lo mismo, con el nombre de antes.

  • describesTheContext()✓ pasa · 100 % cobertura

    Assert.isTrue(true);

  • isSynchronousOutsideAJob()✓ pasa · 100 % cobertura

    Assert.isFalse(AsyncContext.isAsync(), '…');

Con el código bien, los dos pasan. Rompe isAsync() y mira cuál se da cuenta.

Rompe AsyncContext a propósito y mira qué tests se enteran: el que solo cubre y el que comprueba.

La nutria: El «resultado esperado» de tu caso de prueba

En una hoja de casos de UAT, cada fila tenía tres columnas: pasos, resultado esperado y resultado real. Un caso sin resultado esperado no se puede dar por bueno ni por malo. El Assert es esa columna: sin él, el test «pasa» diga lo que diga el código.

La nutria: ¿Y por qué no un Flow? Aquí Flow piensa igual

Con franqueza: los tests de Flow también llevan comprobaciones, las Assertions, y la idea es exactamente esta: qué debería valer el registro después de ejecutar el flow. Si ya las escribías, ya sabes escribir un Assert. La diferencia está en el alcance: en Apex compruebas cualquier valor, también el de un método que no toca ningún registro, como describe().