Consejos y mejores prácticas para probar integraciones de Salesforce

integración de salesforce

Las pruebas de Salesforce lo ayudarán a validar su Integraciones de Salesforce y funcionalidades con otras aplicaciones empresariales. Una buena prueba cubre todos los módulos de Salesforce desde cuentas hasta clientes potenciales, desde oportunidades hasta informes y desde campañas hasta contactos. Como ocurre con todas las pruebas, existe una forma buena (eficaz y eficiente) de hacer una prueba de Salesforce y una forma incorrecta. Entonces, ¿cuáles son las buenas prácticas de prueba de Salesforce?

  • Utilice las herramientas de prueba adecuadas - Las pruebas de Salesforce se realizan en el navegador o en un entorno basado en eclipse. Tanto los navegadores más recientes como eclipse tienen excelentes herramientas de depuración y puede combinarlas con clases de prueba para obtener resultados muy útiles. Sin embargo, si necesita más, debe utilizar Apex Interactive Debugger (o simplemente Apex) de Force.com. Tenga en cuenta que también puede usar Salesforce Lightning Inspector, una extensión de Chrome, para probar específicamente Salesforce Lightning. Apex es un Force.com lenguaje de programación propietario de la plataforma que tiene grandes similitudes con Java. Es un lenguaje de programación orientado a objetos, insensible a mayúsculas y minúsculas, que sigue la sintaxis de notación de puntos y corchetes. Puede utilizar Apex para ejecutar funciones programadas durante la mayoría de los procesos de Force.com, incluidos enlaces y botones personalizados, actualizaciones, eliminaciones y controladores de eventos de inserción de registros a través de la programación o los controladores personalizados de la página de Visualforce.
  • Utilice convenciones de nomenclatura adecuadas: Es muy importante nombrar correctamente sus métodos de prueba antes de comenzar a escribir pruebas. El nombre del método de prueba debe tener tres partes. Estos son nameOfMethod (nombre del método individual que está probando, como insertar / actualizar / eliminar / recuperar al probar un activador, información sobre TestPath que es flexible, como contacto nulo si está probando que el contacto es nulo y válido al probar un camino positivo / negativo.
  • Garantice una cobertura del 100% - Aunque la directiva estándar de Salesforce es que la prueba unitaria debe tener una cobertura del 75% de su código (menos las clases de prueba, las llamadas a System.debug y los métodos de prueba) y no podrá implementar el código Apex o empaquetar aplicaciones de AppExchange, debe tenga en cuenta que esto es solo un estándar y su objetivo debe ser una cobertura del 100%. Pruebe todos los casos positivos / negativos y los datos que estén presentes y no presentes. Otros consejos importantes cuando se trata de cobertura de código son:
    • Debe ejecutar pruebas para actualizar los números de cobertura del código, ya que estos números no se actualizan cuando se actualiza el código Apex hasta que se vuelven a ejecutar las pruebas.
    • Si ha habido una actualización en la organización desde la última ejecución de prueba, existe el riesgo de que los números de cobertura del código sean incorrectos. Vuelva a ejecutar las pruebas para obtener la estimación correcta.
    • El porcentaje de cobertura de código no incluye la cobertura de código de las pruebas de paquetes administrados, con la única excepción de cuando estas pruebas hacen que se activen los desencadenantes.
    • La cobertura depende del número total de líneas de código. Si agrega o elimina líneas de código, afectará el porcentaje.
  • Casos de prueba en clases y controladores - En el desarrollo de Salesforce, la mayoría de los desarrolladores crean clases y archivos de controlador separados para cada función. Esto se hace para que la codificación sea más organizada, más fácil, reutilizable y portátil. Sin embargo, debe tener en cuenta que, si bien esto es más fácil, no es más eficiente. Logrará la portabilidad si el código de prueba está en la clase original y el código del controlador en sí mismo, ya que no se perderá ninguna clase de prueba al migrar de sandbox a producción.
  • Utilice System.assert () - En Apex, System.assert() se utiliza para comprobar las condiciones. Esta es una funcionalidad importante ya que le permite determinar si el método ha realizado una función en particular como se esperaba. Debe usar System.assertEquals () y System.assertNotEquals () entre las funcionalidades críticas, no solo lo ayuda a determinar si el código se ha ejecutado como debería, sino también a garantizar que no se escriban datos erróneamente si el código sale mal.
  • Prueba completa - Las pruebas deben cubrir todo. Debe realizar pruebas funcionales, pruebas de carga, pruebas de seguridad y pruebas de implementación.
  • Pruebas unitarias - Debe tener pruebas unitarias para verificar que los registros individuales produzcan el resultado correcto y esperado. Si bien el uso de una prueba gigante que cubre todo el código puede parecer una buena idea, tenga en cuenta que los resultados generados serán más difíciles de depurar y las fallas serán más difíciles de entender. Una prueba unitaria debe cubrir un pequeño subconjunto de la funcionalidad que se está probando.
  • Casos de prueba a granel - Un buen código de prueba (disparador, excepción o clase) puede estar involucrado para varios cientos de registros (200 para Apex). Debe aprovechar esto y probar no solo los registros individuales, sino también los casos masivos.
  • Pruebas positivas - Pruebe para asegurarse de que el comportamiento esperado se produzca a través de todas las permutaciones esperadas. La prueba debe verificar que el usuario completó correctamente el formulario y que no superó los límites.
  • Pruebas negativas - Pruebe los casos negativos para asegurarse de que los mensajes de error se produzcan correctamente. Ejemplos de tales casos negativos son no poder especificar montos negativos y no poder agregar fechas futuras. Las pruebas negativas son importantes porque el manejo correcto cuando las cosas van mal puede marcar la diferencia.
  • Automatizar las pruebas - Tradicionalmente, las pruebas de Salesforce eran manuales. Debería considerar las pruebas automatizadas ya que ofrece más ventajas. Éstas incluyen:
    • Las pruebas manuales lo hacen susceptible a errores, ya que las pruebas las realizan humanos y no robots. Los robots sobresalen en actividades repetitivas, mientras que los humanos cometen errores debido al aburrimiento, la concentración y la consistencia reducidas y la tendencia a tomar atajos.
    • Las pruebas manuales son repetitivas, formuladas y agotadoras. Es mejor que el equipo de pruebas haga un trabajo más exploratorio.
  • Ejecute cada rama de lógica de código - Cuando se usa la lógica condicional (cuando se han incluido operadores ternarios), se debe ejecutar cada rama de la lógica del código.
  • Utilice entradas no válidas y válidas para llamadas a métodos: Las llamadas a métodos deben realizarse utilizando entradas válidas y no válidas.
  • Pruebas completas - Asegúrese de que las pruebas se completen correctamente; no deben pasar por ninguna excepción a menos que se esperen errores. Maneje todas las excepciones detectadas: detectarlas no es lo suficientemente bueno.
  • Utilice ORDER BY Palabras clave - Para asegurarse de que sus registros se devuelvan en el orden que espera, utilice las palabras clave ORDER BY.
  • No asuma que los ID de registro están ordenados secuencialmente - Evite el error común de asumir que los ID de registro están ordenados en orden secuencial. Los ID no están en orden ascendente, a menos que haya insertado varios registros con la misma solicitud.
  • Llame a Test.startTest () y Test.stopTest () - Cuando ejecuta una prueba unitaria de Apex, obtendrá una cobertura de código superior al 75% que es obligatoria en Salesforce. Debe llamar a stopTest antes de las aserciones para forzar la finalización de los códigos asincrónicos que aún podrían estar ejecutándose. Ejecute consultas nuevas para obtener resultados finales ya que otro código puede cambiar los datos. UsingTest.startTest () y Test.stopTest () asegura que usted ponga la prueba en una caja de arena dentro de sus límites reguladores. De esta manera, el código de configuración que use no interferirá y le dará falsos negativos o positivos en torno a los límites del regulador. Test.stopTest () también asegura que las llamadas @future se completarán para las pruebas.
  • Legibilidad - La legibilidad es muy importante en las pruebas unitarias. Los nombres de las pruebas deben incluir la acción específica que se tomará y el resultado esperado. El método debe ser descriptivo y breve. El método debe ser tal que pueda reutilizarse en diferentes pruebas.
  • Cree grandes conjuntos de datos de prueba antes de comenzar Dado que sus pruebas se ejecutarán en diferentes entornos sandbox y de producción, cree grandes conjuntos de datos de prueba antes de llamar a startTest para asegurarse de que la prueba tenga límites de ejecución completos. Por defecto, Salesforce Github ejecuta pruebas aisladas de los datos de producción. Cuando necesite datos del sistema, como un perfil, consulte para obtener lo correcto para ese entorno específico.
  • Genere sus propios datos de prueba - Los datos de prueba que utilice deben generarse en la prueba. Puede generar estos datos utilizando la anotación @testSetup y una clase TestUtils no solo para asegurarse de que tiene los datos correctos, sino también para asegurarse de que todas las pruebas se ejecuten en un entorno de pruebas para desarrolladores sin requisitos de datos.
  • Evite operaciones nulas AKA sin operación - Muchos probadores utilizan operaciones nulas AKA sin operación. Son códigos inútiles que no hacen nada. Dado que ya están en su base de código, se sumarán a su porcentaje de cobertura.
  • Ejecución de prueba en paralelo - Cuando inicia las pruebas desde la interfaz de usuario de Salesforce o la Consola del desarrollador, las pruebas se ejecutarán en paralelo. Esta es una característica importante ya que acelera el tiempo de ejecución de la prueba. Sin embargo, debe tener en cuenta que esto puede provocar problemas de contención de datos y, si sospecha que esto podría suceder, desactive la ejecución en paralelo. Las causas más comunes de problemas de contención de datos que a menudo conducen a errores UNABLE_TO_LOCK_ROW son:
    • Cuando las pruebas están destinadas a actualizar los mismos registros al mismo tiempo. La actualización de los mismos registros suele ocurrir cuando las pruebas no crean sus propios datos.
    • Cuando hay un punto muerto en las pruebas que se ejecutan en paralelo e intentan crear registros que tengan valores de campo de índice coincidentes. Se producirá un punto muerto cuando 2 pruebas en ejecución se hayan puesto en cola para revertir datos (esto ocurre cuando 2 pruebas ingresan registros que tienen los mismos valores de campo de índice únicos en diferentes órdenes).
    • Para desactivar la ejecución de la prueba en paralelo, vaya a Configuración, ingrese Prueba de Apex, vaya al cuadro de diálogo Opciones de ejecución de la prueba de Apex, seleccione Deshabilitar la prueba de Apex en paralelo, haga clic en Aceptar.

Deshabilitar las pruebas de Apex paralelas

Contrata a un profesional para el trabajo, ya que tendrá la experiencia y la formación necesarias para hacer una buena prueba, lo que también te da tranquilidad. Contratar a un profesional le permite concentrarse en su negocio principal. También le ahorra dinero ya que no necesitará un equipo interno para el trabajo.

¿Qué piensas?

Este sitio usa Akismet para reducir el correo no deseado. Descubra cómo se procesan los datos de sus comentarios.