Escriba aserciones de Apex claras e intencionales con la nueva clase Assert ☁️

Una de las grandes mejoras nuevas de la versión Winter '23 es una clase Assert dedicada. A medida que continuamos ampliando nuestra inversión con Apex y la capacidad de prueba, esta actualización hará que sea más fácil encontrar todos los métodos de afirmación que necesita en un solo lugar. Echemos un vistazo a cómo se compara esto con los métodos actuales para afirmar sus pruebas y cómo puede comenzar a usarlo hoy.

Introducción a la clase de afirmación de Apex

Apex ya tiene métodos de sistema, como assert , assertEquals y assertNotEquals , para escribir aserciones en las pruebas de Apex. Estos métodos han estado aquí durante décadas y funcionan según lo previsto, incluso hoy. No tenemos planes inmediatos para retirar estos métodos del sistema. Aún así, lo alentamos a usar la nueva clase Assert y buscar oportunidades para usarla en su código existente. La nueva clase Assert tiene métodos adicionales para que escriba afirmaciones claras e intencionales. La otra ventaja notable de la nueva clase Assert es que si la afirmación da como resultado una excepción, es más fácil de leer y comprender.

Para demostrar la nueva clase, actualicé las aserciones de Apex para todas las clases de prueba para la aplicación de muestra apex-recipes . En el camino, tuve la oportunidad de usar algunos de los nuevos métodos de la clase Assert. En este blog, compartiré algunas áreas que puede observar en su base de código donde podría usar la nueva clase Assert para mejorar la legibilidad de las pruebas de Apex.

Usando Assertion.Fail() para devolver intencionalmente un error fatal

Antes de la nueva clase Assert, habría encontrado patrones, como el que se muestra a continuación, para detener intencionalmente la ejecución del código en su clase de prueba y devolver un error fatal.

El código anterior es menos legible. La declaración System.assert(false) hace que sea menos obvio que queremos fallar el código intencionalmente. Modifiquemos el código anterior para usar el nuevo método Assert.Fail() . El código modificado está abajo.

Como puede observar, se vuelve obvio con la palabra "falla" que queremos fallar en la ejecución del código en una línea específica si no se ha producido la excepción esperada.

Usando Assertion.isInstanceOfType() para afirmar la instancia del objeto

Tomemos un patrón de ejemplo de aserciones escritas en el código de prueba de Apex para afirmar que la instancia del objeto es del tipo especificado con el método System.assert .

Modificando el código anterior para usar la nueva clase Assert y usando el método isIntanceofType() , veremos que la legibilidad ha mejorado mucho.

SUGERENCIA: tenga en cuenta que el método Assert isInstanceOfType acepta el primer parámetro como el tipo real, seguido del tipo esperado y luego el mensaje personalizado. Mientras que para el resto de los métodos Assert, el primer parámetro es el resultado esperado seguido del resultado real y luego el mensaje personalizado.

Usando Assert.isNull() para afirmar los valores nulos

Para agregar claridad a la forma en que verifica los valores nulos en sus pruebas, hemos introducido los Assert.IsNull() y Assert.isNotNull() . Echemos un vistazo a cómo se compara esto con los métodos del sistema y cómo podemos aumentar la legibilidad.

El siguiente código usa System.assert y tiene una expresión para verificar si el objeto NO es nulo.

El código anterior es correcto, pero debido a que la clase Assert ahora ofrece un método adecuado para la comparación nula, se puede hacer más legible de la siguiente manera.

Usar Assert.areEqual() en lugar de System.assertEquals() para mayor claridad

El método Assert.areEqual es muy similar a System.assertEquals . Afirma que dos valores son iguales. La ventaja de la nueva clase es que se lee mejor, y si las aserciones fallan durante la ejecución de la prueba, tiene un mejor mensaje de error. Aquí hay un ejemplo simple que compara el uso de System.assertEquals vs Assert.areEqual .

El siguiente código usa System.assertEquals .

Con Assert.areEqual , el código anterior se puede modificar como se muestra a continuación. Observe que reemplazamos System.assetEquals con Assert.areEqual y nada más cambió.

Usar Assert.isTrue() en lugar de System.assert() para mayor claridad

En este punto, has observado cómo estos nuevos métodos tienen nombres más precisos que sus contrapartes anteriores. Sin embargo, este puede volverse un poco más confuso, System.assert() y Assert.isTrue() funcionan de manera similar, pero sus nombres no son precisamente los mismos. ¡Afortunadamente, no es Assert.assert(condition) para aún más confusión!

El siguiente código usa System.assert para aserciones.

Con Assert.isTrue , el código anterior se modifica como se muestra a continuación. Observe cómo el código es más legible y obvio.

También hay métodos equivalentes a operadores NO disponibles en la clase Assert. Por ejemplo, hay Assert.isFalse() que afirma que la condición es falsa. El objetivo con Assert.isFalse() es reemplazar un fragmento de código System.assert(!containsForce) con la negación principal. Assert.isFalse() aclara que la condición debe ser falsa.

Explore la lista completa de los métodos disponibles en la documentación de Apex.

Crear buenos mensajes de error

Es posible que haya notado que todos mis fragmentos de código en este blog usan el último parámetro opcional de los métodos Assert para agregar un mensaje de error personalizado. Es una buena práctica escribir mensajes de error claros, de modo que si la prueba falla más tarde, debería ayudarlo a diagnosticar qué falló.

Los nuevos métodos de la clase Assert también fomentan la elaboración de buenos mensajes al restringir el último parámetro a una cadena. System.assert() aceptó un objeto para el mensaje y convirtió ese objeto en una representación de cadena, lo que a menudo es menos útil para depurar pruebas fallidas. Los nuevos métodos Assert necesitan explícitamente una cadena. Por lo tanto, no puede usar un sObject o un mapa en los parámetros del mensaje. Queremos que sea muy explícito acerca del mensaje de error y que piense detenidamente en los mensajes de error.

último consejo

También es posible que ya tenga una clase llamada "Afirmar" en su sistema. Salesforce Platform no le impide crear una clase con Name Assert, pero tener esa clase en su organización puede causar conflictos cuando intenta usar la nueva clase Assert del espacio de nombres del sistema. Afortunadamente, hay una solución. Puede agregar el espacio de nombres del sistema a la clase Assert en tales escenarios. Por ejemplo, escriba System.Assert.areEqual en lugar de Assert.areEqual y podrá usar las nuevas clases de manera segura.

Conclusión

La nueva clase System.Assert proporciona métodos que manejan todo tipo de aserciones y comparaciones lógicas. Cuando utiliza un método de afirmación destinado a una condición específica, mejora la claridad de su código Apex. Y si la aserción da como resultado una excepción, es más fácil de leer y comprender.

Actualizamos cada clase de prueba en la aplicación de muestra apex-recipes para usar las nuevas clases System.Assert . Estamos complacidos con lo fácil que fue actualizar las afirmaciones anteriores, gracias a los sistemas de integración continua que tenemos para el proyecto. En el futuro, para todas las nuevas pruebas de Apex que escribamos, nos aseguraremos de usar la nueva clase Assert.

Sobre el Autor

Mohith Shrivastava es promotor de desarrollo en Salesforce con una década de experiencia en la creación de productos a escala empresarial en la plataforma de Salesforce. Actualmente se está enfocando en las herramientas para desarrolladores de Salesforce, Apex y Lightning Web Components en Salesforce. Mohith se encuentra actualmente entre los principales contribuyentes en Salesforce Stackexchange, un foro de desarrolladores donde los desarrolladores de Salesforce pueden hacer preguntas y compartir conocimientos. Puedes seguirlo a través de su Twitter @msrivastav13.