Consellos e mellores prácticas para probar integracións de Salesforce

integración de Salesforce

As probas de Salesforce axudaranche a validar a túa configuración personalizada Integracións de Salesforce e funcionalidades con outras aplicacións empresariais. Unha boa proba abrangue todos os módulos de Salesforce desde contas a clientes potenciais, desde oportunidades a informes e desde campañas a contactos. Como é o caso de todas as probas, hai unha boa forma (eficaz e eficiente) de facer unha proba de Salesforce e unha mala. Entón, que é Salesforce probando boas prácticas?

  • Use as ferramentas de proba adecuadas - As probas de Salesforce acontecen no navegador ou nun ambiente baseado en eclipse. Tanto os navegadores máis recentes como o eclipse teñen excelentes ferramentas de depuración e podes combinalas con clases de proba para obter resultados moi útiles. Non obstante, se precisa máis, debería empregarse o Apex Interactive Debugger (ou simplemente Apex) de Force.com. Ten en conta que tamén podes usar Salesforce Lightning Inspector, unha extensión cromada, para probar específicamente Salesforce Lightning. Apex é un Force.com linguaxe de programación propietaria da plataforma que ten grandes similitudes con Java. É unha linguaxe de programación orientado a obxectos, sen distinción de maiúsculas e minúsculas, que segue unha paréntesis rizada e unha sintaxe de notación de puntos. Podes usar Apex para executar funcións programadas durante a maioría dos procesos de Force.com, incluíndo ligazóns e botóns personalizados, actualizacións, eliminacións e controladores de eventos de inserción de rexistros a través de controladores ou programación personalizados da páxina Visualforce.
  • Usar convenios de nomeamento adecuados - É moi importante o nome adecuado dos métodos de proba antes de comezar a escribir probas. O nome do método de proba debe ter tres partes. Estes son nameOfMethod (nome do método individual que está probando, como inserir / actualizar / eliminar / recuperar cando se proba un disparador, información sobre TestPath que é flexible como o contacto nulo se está a probar que o contacto é nulo e é válido cando se proba un camiño positivo / negativo.
  • Garantir un 100% de cobertura - Aínda que a directiva estándar de Salesforce é que a proba unitaria debería ter unha cobertura do 75% do seu código (menos clases de proba, chamadas a System.debug e métodos de proba) e non poderá despregar código Apex nin empaquetar aplicacións AppExchange, debería teña en conta que isto é só un estándar e o seu obxectivo debe ser un 100% de cobertura. Proba todos os casos positivos / negativos e os datos presentes e non presentes. Outros consellos importantes á hora de cubrir o código son:
    • Debería realizar probas para actualizar os números de cobertura do código, xa que estes números non se actualizan cando se actualiza o código Apex ata que se volven executar.
    • Se houbo unha actualización na organización desde a última proba, existe o risco de que os números de cobertura do código sexan incorrectos. Volva realizar as probas para obter a estimación correcta.
    • A porcentaxe de cobertura de código non inclúe a cobertura de código das probas de paquetes xestionados, sendo a única excepción cando estas probas provocan o disparo dos disparadores.
    • A cobertura depende do número total de liñas de código. Se engade ou elimina liñas de código, afectará a porcentaxe.
  • Casos de proba en clases e controladores - No desenvolvemento de Salesforce, a maioría dos desenvolvedores crean clases e ficheiros de controladores separados para cada función. Isto faise para que a codificación sexa máis organizada, máis doada, reutilizable e portátil. Non obstante, debes ter en conta que, aínda que isto é máis sinxelo, non é máis eficiente. Logrará a portabilidade se o código de proba está na clase orixinal e no propio código do controlador, xa que non perderá ningunha clase de proba cando migre de sandbox a produción.
  • Usar System.assert () - En Apex, Sistema.afirmar() úsase para comprobar as condicións. Esta é unha funcionalidade importante xa que permite determinar se o método realizou unha función concreta como se esperaba. Debes usar System.assertEquals () e System.assertNotEquals () entre funcións críticas non só che axuda a determinar se o código se executou como debería, senón tamén a asegurarte de que non se escriban datos de forma errónea se o código sae mal.
  • Proba integral - As probas deben abarcar todo. Debería facer probas funcionais, probas de carga, probas de seguridade e probas de implantación.
  • Probas unitarias - Debería facer probas unitarias para verificar que os rexistros individuais producen o resultado correcto e esperado. Mentres se usa unha proba xigante que abrangue todo o código pode parecer unha boa idea, teña en conta que os resultados xerados serán máis difíciles de depurar e que o fallo será máis difícil de entender. Unha proba unitaria debería cubrir un pequeno subconxunto da funcionalidade que se está a probar.
  • Casos de proba a granel - Un bo código de proba (disparador, excepción ou clase) pode implicarse ata varios centos de rexistros (200 para Apex). Debería aproveitar isto e probar non só rexistros individuais, senón tamén casos masivos.
  • Probas positivas - Proba para comprobar se o comportamento esperado se produce a través de toda a permutación esperada. A proba debe comprobar que o usuario encheu correctamente o formulario e que non superou os límites.
  • Probas negativas - Proba os casos negativos para asegurarse de que as mensaxes de erro se producen correctamente. Exemplos de tales casos negativos son que non se poden especificar cantidades negativas e non se poden engadir datas futuras. As probas negativas son importantes porque o manexo correcto cando as cousas van cara ao sur pode marcar a diferenza.
  • Automatizar probas - Tradicionalmente, as probas de Salesforce eran manuais. Debería considerar as probas automatizadas xa que isto ofrece máis vantaxes. Estes inclúen:
    • A proba manual faino susceptible a erros xa que a proba é realizada por humanos e non por robots. Os robots destacan en actividades repetitivas mentres os humanos cometen erros debido ao aburrimento, a concentración e consistencia reducidas e a tendencia a cortar cantos.
    • A proba manual é repetitiva, fórmula e cansativa. É mellor que o equipo de probas faga un traballo máis exploratorio.
  • Executa cada rama de lóxica de código - Ao usar lóxica condicional (cando incluíu operadores ternarios), debería executarse cada rama da lóxica de código.
  • Usar entradas non válidas e válidas para chamadas a métodos - As chamadas a métodos deben facerse empregando entradas non válidas e válidas.
  • Probas completas - Asegúrese de que as probas finalizan con éxito; non deben realizarse excepcións a menos que se esperen erros. Xestionar todas as excepcións capturadas: non as capturas non é o suficientemente boa.
  • Usar ORDER BY Keywords - Para asegurarte de que os teus rexistros se devolven na orde que esperas, usa as palabras clave ORDER BY.
  • Non asuma que os ID de rexistro están organizados secuencialmente - Evite o erro común de asumir que os ID de rexistro están organizados en orde secuencial. Os ID non están en orde ascendente, a menos que inseriu varios rexistros coa mesma solicitude.
  • Chama a Test.startTest () e Test.stopTest () - Cando executa unha proba unitaria Apex, obterá máis do 75% de cobertura de código obrigatoria en Salesforce. Debería chamar a stopTest antes das afirmacións para forzar a finalización de códigos asíncronos que aínda poden estar en execución. Realice novas consultas para obter resultados finais, xa que outro código pode cambiar os datos. UseTest.startTest () e Test.stopTest () garante que probe a proba dentro dos seus límites de gobernador. Deste xeito, o código de configuración que empregue non interferirá e dará falsos negativos ou positivos en torno aos límites do gobernador. Test.stopTest () tamén garante que as chamadas @future completaranse para probar.
  • Lexibilidade - A lexibilidade é moi importante nas probas unitarias. Os nomes das probas deben incluír a acción específica que se debe realizar e o resultado esperado. O método debe ser descritivo e curto. O método debe ser tal que poida ser reutilizable en diferentes probas.
  • Construír grandes conxuntos de datos de proba antes de startTest - Dado que as probas executaranse en diferentes contornos de produción e sandbox, cree grandes conxuntos de datos de proba antes de chamar a startTest para garantir que a proba ten límites de execución completos. Por defecto, Salesforce Github executa probas illadas dos datos de produción. Cando precisa datos do sistema como un perfil, realice unha consulta para obter o correcto para ese ambiente específico.
  • Xera os teus propios datos de proba - Os datos da proba que use deben xerarse na proba. Podes xerar estes datos usando a anotación @testSetup e unha clase TestUtils para non só asegurarte de que tes os datos correctos, senón tamén para asegurarte de que todas as probas se executan nunha caixa de proba do desenvolvedor sen necesidade de datos.
  • Evite operacións nulas AKA sen operacións - Moitos probadores usan operacións nulas AKA sen operacións. Son códigos inútiles que non fan nada. Como xa están na base de códigos, engadiranse á porcentaxe de cobertura.
  • Execución de probas paralelas - Cando inicie probas desde a interface de usuario de Salesforce ou a Consola para desenvolvedores, as probas executaranse en paralelo. Esta é unha característica importante xa que acelera o tempo de execución da proba. Non obstante, debes ter en conta que isto pode provocar problemas de disputa de datos e, se sospeitas que isto pode ocorrer, desactiva a execución paralela. As causas máis comúns de problemas de contención de datos que adoitan levar a erros UNABLE_TO_LOCK_ROW son:
    • Cando as probas están destinadas a actualizar os mesmos rexistros ao mesmo tempo. A actualización dos mesmos rexistros normalmente ocorre cando as probas non crean os seus propios datos.
    • Cando hai un punto morto nas probas que se executan en paralelo e intentan crear rexistros que teñan valores de campo de índice coincidentes. Un bloqueo producirase cando hai dúas probas en execución en cola para recuperar os datos (isto ocorre cando 2 probas rexistros de entrada que teñen os mesmos valores de campo de índice únicos en diferentes ordes).
    • Para desactivar a execución da proba paralela, vaia a Configuración, ingrese a proba Apex, vaia ao diálogo Opcións de execución da proba Apex, seleccione Desactivar a proba paralela de Apex e faga clic en Aceptar.

Desactivar a proba de ápice paralelo

Contrata a un profesional para o traballo xa que terá a experiencia e o adestramento necesarios para facer unha boa proba, o que tamén che proporciona tranquilidade. Contratar un profesional permítelle concentrarse no seu negocio principal. Tamén aforras cartos xa que non necesitarás un equipo interno para o traballo.

¿Que pensas?

Este sitio usa Akismet para reducir o spam. Aprende a procesar os teus datos de comentarios.