• Accueil / Salesforce / Low Code a…
, Low Code a encore besoin de tests unitaires<span class="wtr-time-wrap after-title"><span class="wtr-time-number">7</span> minutes de lecture</span>

Low Code a encore besoin de tests unitaires7 minutes de lecture


, Low Code a encore besoin de tests unitaires<span class="wtr-time-wrap after-title"><span class="wtr-time-number">7</span> minutes de lecture</span>

introduction

Tout d’abord, permettez-moi de préciser qu’il ne s’agit pas de dumping sur du code bas ou d’une tentative comme King Canute de repousser l’avancée des clics et non du code en faveur d’avoir à écrire chaque petite automatisation dans Apex. Quand j’ai commencé à travailler avec Salesforce en 2008, je n’ai pas regardé les règles de workflow et je n’ai pas pensé « Oh nez, je voulais écrire un tas de code pour mettre à jour le contenu d’un champ de zone de texte riche », j’ai pensé « C’est cool, quelqu’un d’autre peut configurer l’automatisation simple et je peux travailler sur les scénarios les plus difficiles ».

Du côté des développeurs, nous avons passé des années à convaincre les gens que les tests unitaires sont une bonne chose, et nous avons même un développement piloté par les tests qui transforme les exigences en tests dans un premier temps, après quoi nous écrivons le code qui permet aux tests de réussir. Certaines personnes se plaignent encore d’avoir à écrire des tests pour les déployer en production, mais la plupart d’entre nous reconnaissent que c’est une bonne chose et nous serons reconnaissants de devoir le faire à un moment donné dans le futur.

Donc, quand je vois des messages (de Salesforce et de bien d’autres) selon lesquels ne pas être en mesure d’écrire des tests unitaires est un avantage de la plate-forme Low Code dont on parle, cela me semble une tentative de qualifier un négatif de positif sans expliquer les inconvénients . Vous pourrez peut-être mettre les choses en production plus rapidement, mais de façon réaliste, vous devriez être échanger l’effort de test unitaire pour une AQ et une UAT étendues effort, pas seulement de faire la différence. Si vous ne le faites pas, il est fort probable que vous ayez des bogues en production plus rapidement !

Les tests unitaires sont importants

Les tests unitaires consistent essentiellement à écrire du code qui vérifie que l’autre code fonctionne comme prévu. Maintenant, ce low code inclut de plus en plus de logique métier, et le complexité cyclomatique augmente, les tests unitaires sont plus que jamais nécessaires. Soit dit en passant, j’ai ressenti la même chose lorsque les composants Aura ont été introduits pour la première fois et j’ai déplacé un tas de logique métier vers le front-end, j’ai donc fait un conférence à Dreamforce sur les tests unitaires ceux.

Les tests unitaires offrent les avantages suivants, qui s’appliquent également à tous les types de code :

  • Plus vous trouvez un bogue près du développeur, moins il en coûte de le rectifier.
  • Avec une bonne couverture de test et des assertions appropriées, vous pouvez apporter des changements en toute confiance que si vous rompez le comportement sur lequel quelqu’un d’autre s’appuie, un ou plusieurs tests échoueront (c’est le principal avantage pour moi).
  • Si quelqu’un d’autre fait une modification qui casse votre code (l’ajout d’une règle de validation est la situation classique ici), la prochaine fois que les tests unitaires seront exécutés, cela sera pris en compte.
  • Cela rend vos utilisateurs plus heureux, car davantage de bogues sont détectés pendant le cycle de développement plutôt qu’après que le système leur a été mis à disposition.

Test No et Low Code

No Code a tendance à être des unités discrètes qui peuvent être utilisées pour appliquer l’automatisation, comme une règle de workflow qui a envoyé un e-mail et mis à jour certains champs si un enregistrement est passé à un état spécifique, ou une règle de validation qui vérifie les dépendances entre les champs. Il ne sert à rien de tester des unités avec de nombreuses combinaisons différentes de champs d’enregistrement, pour la même raison que dans Apex, nous n’écrivons pas de tests unitaires pour vérifier que le compilateur et l’exécution fonctionnent comme prévu. Le moteur de workflow est testé par Salesforce et nous pouvons lui faire confiance. L’exécution manuelle de quelques enregistrements est idéale pour tester un scénario comme celui-ci, car la logique qui déclenche le flux de travail ou la règle de validation est généralement très petite et change rarement.

Dans Low Code, un certain nombre d’éléments de ce type sont assemblés dans une automatisation plus complexe dans un flux, y compris la logique conditionnelle et les boucles, ce qui est beaucoup plus proche du code traditionnel. Le moyen d’expression peut être différent, mais nous sommes maintenant dans un monde de complexité et de réutilisation, surtout s’il s’agit d’un sous-flux qui peut être déposé dans n’importe quel autre flux. Dans ce monde, il est logique d’exécuter le flux avec une variété d’entrées, avec la base de données sous-jacente dans une variété d’états, et en tant qu’utilisateurs avec une variété de profils, et de nombreuses combinaisons différentes si celles-ci. Faire tout cela manuellement à chaque fois qu’il y a un changement ne va pas être pratique. Le faire via des outils d’automatisation de test est possible, mais a tendance à tester une transaction entière plutôt que la plus petite unité, et cela ne peut pas se produire en production car les modifications ne sont pas annulées à la fin du test.

À l’heure actuelle, la seule façon de le faire est d’écrire des tests Apex dans un véritable environnement de test. Cela va quelque peu à l’encontre d’un avantage clé du flux pour les petites organisations : elles auraient toujours besoin d’un développeur parmi leur personnel pour écrire les tests unitaires pour les flux que les administrateurs ont créés. (Légèrement hors sujet, je pense également qu’il serait difficile de trouver un développeur qui souhaite ce travail pendant un certain temps, vous devez donc vous préparer à un taux de désabonnement important). Apex ne peut cependant pas se connecter directement au moteur de flux dans tous les cas, donc pour l’enregistrement déclenché, il y a un compromis que la transaction doit réellement se terminer, après quoi la vérification que l’aspect du flux a eu l’effet souhaité peut avoir lieu. Cela ressemble plus à un test d’intégration, car il existe d’autres aspects de l’automatisation qui pourraient avoir un impact sur le travail effectué par le flux, mais c’est certainement mieux que rien. Une fois que vous avez des tests Apex, vous pouvez tirer parti de nombreuses solutions existantes pour une exécution planifiée, en les intégrant à un pipeline de déploiement, etc.

Que pourrait réserver l’avenir

Idéalement, nous avons besoin d’un générateur de tests Low Code capable d’exécuter des flux/sous-flux de manière isolée et de générer des tests unitaires réels, avec des assertions, qui s’exécutent dans un environnement isolé où les transactions sont annulées. Générer Apex me semble être une approche raisonnable, tout comme cibler un autre moteur. Compte tenu de tous les efforts déployés au cours des dernières années, il semble que cela devrait être faisable.

Il y a de nombreuses années, lorsque Salesforce était considéré comme un shadow IT, mon approche pour intégrer les départements technologiques consistait à leur dire comment leur gouvernance et leurs meilleures pratiques étaient nécessaires pour garantir que les choses étaient faites correctement et pouvaient évoluer. Apporter les meilleures pratiques du monde Pro Code est un bon moyen de faire participer tout le monde à l’approche Low Code.





Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Vous utilisez Pardot depuis un certain temps mais vous n'êtes pas sûr d'en
exploiter tout le potentiel

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer