Je voudrais écrire sur une technique que j'utilise dans le composant AJ_Tools_UnitTest qui est vraiment le coeur même du composant. En fait, quand j'ai écrit le composant, j'ai littéralement écrit 5 lignes de code pour que mon composant fonctionne. Oui, seulement 5 lignes de code étaient nécessaires et représentent le cœur de mon composant, le reste n'est rien d'autre que de l'enrobage esthétique et défensif.
Laissez moi vous montrer :
My première méthode se nomme "New AJ_Tools_UT_describe" et contient 2 lignes de codes :
$0:=New object
$0.assert:=Formula(AJ_Tools_UT_assert )
My seconde méthode se nomme "AJ_Tools_UT_assert" et contient 3 lignes de codes :
$col1:=New collection(This.expected)
$col2:=New collection(This.actual)
This.result:=$col1.equal($col2;ck diacritical)
Avec cela, vous pouvez faire n'importe quel test que vous voulez, mais vous aurez besoin d'utiliser la syntaxe correcte pour les propriétés de l'objet de test et devoir gérer et/ou sauvez le résultat par vos propres moyens.
Je voulais que mon composant fasse un peu plus, donc j'ai écrit du code qui est capable de stocker le résultat de chaque test et de l'analyser pour qu'il soit facile à lire (d'être analysé par un outil externe si nécessaire) et d'afficher le résultat visuellement, ce qui est important pour un développeur afin de voir rapidement où un test échoue et plus important encore, pourquoi !
Regardons ce qui est génial avec ce code.
Je viens du JavaScript donc le typage des variables n'est pas vraiment mon grand ami et je peux facilement penser en dehors de la prison dans laquelle certains développeurs sont piégés. Sans la grande flexibilité de l'objet, il faudrait écrire une méthode pour chaque type de variable à tester.
Ce que j'aime le plus dans ce code, c'est que je n'ai pas besoin de me soucier du type de valeur qui sera testé. Une propriété d'objet peut avoir une valeur d'un type et la ligne de code suivante, le type peut être différent. Je vois déjà des cheveux qui se lèvent. Cela donne une certaine souplesse, mais c'est comme certains outils dangereux, entre de mauvaises mains, cela peut entraîner des dommages sérieux. Utilisez donc cette capacité avec beaucoup de prudence. Pour notre cas, cette flexibilité nous permet d'écrire du code générique vraiment sympa qui simplifie beaucoup le composant en évitant de multiplier de nombreuses méthodes seulement pour changer le type de ce qui va être testé.
Deuxièmement, pourquoi créer 2 collections qui ne contiennent qu'une seule valeur ? En raison de la fonction membre : equal. Cette fonction membre est quelque chose que nous n'avions jamais eu dans 4D auparavant, la possibilité de comparer 2 choses, peu importe le type sans avoir à faire un cast de nos valeurs. Ici tout est automatique et ça marche super bien ! Cette fonction test si 2 collections sont égales et fait un test que l'on appel "deep equal", ce qui signifie que nous pouvons même tester certains objets complexes ce qui n'était pas possible auparavant avec l'opérateur "=" égale. Et cette dernière raison est vraiment génial car sinon, nous n'avons pas de solution pour tester 2 objets de manière simple.
Nous pourrions essayer avec JSON STRINGIFY mais alors, l'ordre des propriétés est important car {"a" : "a" : "a", "b" : "b"} ne sera pas égal à {"b" : "b", "a" : "a"}
Pour ceux qui ont parcouru le code du composant, vous pouvez voir que la majeure partie du code n'est que de l'habillage et la partie vraiment intéressante réside dans 5 lignes de code.
Vous pouvez trouver le code du coeur du composant sur GitHub.