Mocks para callouts

ErpSyncJob, el Queueable del Módulo 9, llama al ERP y después marca las renovaciones como enviadas. Si lo ejecutas en un test tal cual, falla: los métodos de test no pueden hacer callouts. Y aunque pudieran, no querrías que cada despliegue mandara renovaciones de prueba al ERP de verdad.

Un ERP de mentira

private class ErpOkMock implements HttpCalloutMock {
    public HttpResponse respond(HttpRequest req) {
        HttpResponse res = new HttpResponse();
        res.setStatusCode(200);
        res.setBody('{"received": true}');
        return res;
    }
}

Test.setMock(HttpCalloutMock.class, new ErpOkMock());   // desde aquí, cada callout lo contesta el mock

Con Test.setMock, cuando el código ejecuta http.send(req), no sale nada de Salesforce: el mock contesta. Así pruebas lo que de verdad es tuyo, qué haces con la respuesta. Y puedes tener varios mocks: uno que responde 200, otro que responde 500 y otro que lanza una CalloutException, para probar también qué pasa cuando el ERP falla.

La nutria: Tu usuario de prueba, pero para sistemas

Cuando probaba en una sandbox, nunca usaba el correo de un cliente real: creaba un contacto de prueba para que los emails no llegaran a nadie. Un mock es ese contacto de prueba para el ERP: el código hace exactamente lo mismo, pero la llamada no sale.

La nutria: ¿Y por qué no un Flow? Porque el callout vive donde Flow no prueba

En un flow desencadenado por registro, el callout HTTP va en el camino asíncrono, y los tests de Flow no admiten caminos asíncronos. Esa parte del flow se despliega sin probar. En Apex, HttpCalloutMock te deja probar la llamada, la respuesta buena y la mala antes de que nada llegue a producción.