Pruebas unitarias en Salesforce

Escribir Unit Tests para Apex en Salesforce

Comparte la información a tus amigos

Escribir unit tests en Apex es importante para asegurarse que el código funciona y produce el resultado esperado. En este artículo, vamos a aprender escribir pruebas unitarias para Apex classes, triggers, controladores, flujos y procesos en Salesforce.

Consideraciones para Escribir Unit Tests

  • Las clases y métodos de prueba deben crearse con la etiqueta @isTest y pueden ser privados o públicos.
  • Estos métodos deben ser estáticos, no devolver valores y tampoco parámetros.
  • Los datos de test deben estar disponibles para probar la funcionalidad y los datos.
  • Se puede usar @testSetup para configurar datos de prueba en la clase de método.
  • El método que se está probando puede ser llamado directamente desde el método de prueba.
  • Para testear triggers, se deben incluir operaciones DML en los métodos de prueba.
  • Los resultados del test se pueden verificar con el método System.assert().

Anatomía de una clase de prueba en Apex

  • 1° línea: @isTest indica que esta clase de Apex es una clase de prueba.
  • 4° línea: @isSetup indica que este método se utiliza para crear datos de prueba.
  • 9° linea: @isTest indica que este método es un método de prueba.
  • 10° línea: El método debe ser estático y del tipo void, es decir, no debe devolver ningún valor. Además, el método no debe aceptar ningún argumento.
@isTest
private class MyApexClassTest {
  
  @isSetup
  private static void setupTestData() {
    //Create data to use in the test methods.
  }

  @isTest
  private static void myTestMethod() {
    //Test code here.
  }

}

Estructura para Escribir Unit Tests

  • Preparar datos válidos para tests.
  • Ejecutar los métodos que serán probados.
  • Verificar los resultados utilizando afirmaciones y realizando ajustes si es necesario.

Todas las pruebas unitarias siguen la misma estructura para crear datos de prueba. Además, los datos no se comprometen, por lo que no es necesario eliminarlos.

Mejores prácticas al escribir Unit Tests

  • Realizar varios casos de prueba. Por ejemplo, considerar el comportamiento del código positivo, negativo y restringido por el usuario.
  • Los test unitarios deben crear sus propios datos de prueba para no depender de los datos existentes en la organización.
  • No es necesario eliminar datos porque las pruebas unitarias no hacen commit a los cambios.
  • Siempre verificar los resultados usando System.assert().
  • Cuando el resultado esperado no coincide con el actual de System.assert(), se lanza una excepción.
  • Debe probar solo un aspecto del código a la vez para facilitar la comprensión del propósito.
  • Agregue la prueba a un conjunto de pruebas (test suite) cuando se encuentre un nuevo error para simplificar las pruebas de regresión.
  • El Test-driven basado en pruebas o la creación de pruebas unitarias antes de escribir un nuevo código pueden ayudar a comprender cómo se utilizará el código.

Cálculo de cobertura de código

  • Fórmula para calcular la cobertura de código en porcentajes: CCP (número de líneas cubiertas) / (número de líneas cubiertas + número de líneas no cubiertas)
  • No se cuentan y no afectan al porcentaje de cobertura del código: comentarios, nombres de clase, líneas que solo contienen llaves y declaraciones System.debug.

Muestra de prueba para Triggers en Apex

//Trigger Class
trigger ContactTrigger on Contact (before insert) {
  List <String> phoneNumbers = new List <String>();
  List <Account> accountList = new List <Account>();
  Map <String, Account> mapAccounts = new Map <String, Account>();

  if (Trigger.isBefore &amp;&amp; Trigger.isInsert) {
    for (Contact c : Trigger.New) { phoneNumbers.add(c.PhoneNumber); }
    accountList = [SELECT Id, MobilePhone FROM Account WHERE MobilePhone IN :phoneNumbers];
    for (Account a : accountList) { mapAccounts.put(a.MobilePhone, a); }
    if (mapAccounts.size() != 0) {
      for (Contact c : Trigger.New) {
        if (mapAccounts.containsKey(c.PhoneNumber)) {
          c.AccountId = mapAccounts.get(c.PhoneNumber);
        }
      }
    }
  }
}
//Test Class
@isTest
private class ContactTriggerTest {

  @testSetup
  static void createTestData() {
    Account a = new Account(Name='Test Account', MobilePhone = '1234');
    insert a;
  }

  @isTest
  static void testMapping() {
    Contact cont = new Contact(LastName = 'Vallejos', PhoneNumber = '1234');
    insert cont;

    Account acc = [SELECT Id, Name FROM Account WHERE Name = 'Test Account' LIMIT 1];
    Contact cont2 = [SELECT Id, AccountId FROM Contact WHERE Id = :cont.Id];

    System.AssertEquals(acc.Id, cont2.AccountId);
  }
}

Más información

Para más información sobre Salesforce puede visitar El Framework para Pruebas de Salesforce.

Comparte la información a tus amigos

Leave a Comment