Apex Academy
Módulo 10·01·25 min

@isTest y la clase de test

Un test es código que ejecuta tu código y comprueba el resultado. Vive en su propia clase, marcada con @isTest, no toca los datos reales y es lo que Salesforce exige antes de dejarte desplegar.

En Admin esLas pruebas de aceptación (UAT) antes de pasar a producción

✓ En esta sub-lección

  1. 01Escribir una clase de test con @isTest y un método de test.
  2. 02Explicar qué es la cobertura y por qué se exige el 75 %.
  3. 03Ejecutar un test y leer su resultado en tu Developer Org.

La nutria: ¿Te acuerdas? · Repaso del Módulo 9

¿Qué hace falta en tu org para poder desplegar un trigger o una clase a producción?

El puente con el ERP de los Módulos 8 y 9 funciona en la sandbox. Llega el día de desplegarlo y Salesforce lo rechaza: «Average test coverage across all Apex Classes and Triggers is 0%, at least 75% test coverage is required». Nadie escribió un solo test. Este módulo lo arregla, pieza a pieza.

La forma de un test

Apex
@isTest
private class RenewalRowTest {
    @isTest
    static void parsesAValidAmount() {
        Decimal amount = RenewalRow.parseAmount('12500.00');   // 1 · ejecuta tu código
        Assert.areEqual(12500.00, amount);                     // 2 · comprueba el resultado
    }
}
  • @isTest encima de la clase: es código de prueba, no se ejecuta en producción ni cuenta para el límite de tamaño de código de la org.
  • private: nadie más necesita llamar a un test. Y el nombre suele ser el de la clase probada más Test.
  • @isTest encima de cada método static void sin parámetros: cada uno es un caso de prueba, y su nombre dice qué comprueba.

TESTS QUE EJECUTAS

  1. if (String.isBlank(raw)) {
  2. throw new RenewalImportException('Importe vacío');
  3. Decimal amount;
  4. try { amount = Decimal.valueOf(raw); }
  5. catch (TypeException e) { throw new RenewalImportException('…', e); }
  6. if (amount <= 0) {
  7. throw new RenewalImportException('Importe no positivo: ' + raw);
  8. return amount;

63 % de cobertura: por debajo del 75 %. Las líneas en rojo nunca se han ejecutado en un test.

Añade tests y mira qué líneas de parseAmount se ejecutan y cómo sube la cobertura.

La cobertura: qué líneas se ejecutaron

Al pasar los tests, Salesforce apunta qué líneas de tu código se ejecutaron: eso es la . Para desplegar hace falta al menos un 75 % en conjunto, y cada trigger tiene que ejecutarse alguna vez. Pero ojo: la cobertura solo dice qué líneas corrieron, no si hicieron lo correcto. Eso lo dice el Assert, y es la lección 3.

La nutria: Tu UAT, pero automática

Antes de pasar un cambio a producción yo hacía pruebas de aceptación: abrir la sandbox, crear un registro, comprobar que el flow hacía lo que tenía que hacer. Un test de Apex es esa prueba escrita una vez y repetida siempre: en cada despliegue, Salesforce vuelve a pasar todos los tests de la org, y si tu cambio rompe algo de otro, lo sabes antes de que llegue a los usuarios.

La nutria: ¿Y por qué no un Flow? Flow también tiene tests… opcionales

Con franqueza: Flow Builder tiene sus propios tests para flows desencadenados por registro, y conviene usarlos. Pero son opcionales y tienen límites: no cubren caminos asíncronos ni flows de borrado, y solo trabajan con el objeto del flow, sin padres ni hijos. En Apex no es opcional: sin tests no hay despliegue. Por eso un developer escribe el test a la vez que el código.