Datos de prueba y @testSetup
Un test no ve los datos de la org: empieza con la base de datos vacía y fabrica lo que necesita. @testSetup prepara esos datos una vez para todos los métodos de la clase, y todo se deshace al terminar.
✓ En esta sub-lección
- 01Explicar por qué un test no ve los datos de la org.
- 02Preparar datos con @testSetup y recuperarlos con una consulta.
- 03Saber qué pasa con los datos de un test cuando termina.
La nutria: ¿Te acuerdas? · Repaso de la lección 1
¿Dónde va la anotación @isTest?
La siguiente pieza del puente es el guardián de renovaciones del Módulo 8: un trigger que rechaza una segunda renovación abierta para la misma cuenta. Para probarlo hacen falta cuentas y oportunidades. Pero las de tu org no sirven, y no por prudencia: el test ni siquiera las ve.
Cada test empieza con la base de datos vacía
Por defecto, un test no ve los registros de la org: una consulta a Account devuelve cero filas. Es a propósito. Si el test dependiera de datos reales, pasaría en una sandbox y fallaría en otra, o el día que alguien borrara «la cuenta de pruebas». Así que cada test fabrica lo que necesita, y al terminar Salesforce deshace todo lo que el test insertó: nada llega a guardarse.
@testSetup: los datos, una vez para todos
@testSetup
static void setup() {
insert new List<Account>{ new Account(Name = 'Acme'), new Account(Name = 'Globex') };
}
@isTest
static void allowsTheFirstRenewal() {
Account globex = [SELECT Id FROM Account WHERE Name = 'Globex' LIMIT 1]; // se recupera
// …
}Las variables del setup no llegan a los tests; los registros sí. Por eso cada test los recupera con una consulta, por nombre o por algún campo que los identifique. Y como el setup es código normal, sigue las reglas de siempre: un insert por lista, no uno por registro.
LA ORG DE VERDAD
5.000 cuentas de la orgLO QUE VE EL TEST
Paso 1 de 5
Una clase de test con un @testSetup y dos tests. Pulsa Reproducir.
La nutria: ¿Y por qué no un Flow? Porque sus tests no ven al padre