C'est une évidence : nous ne pouvons pas tous travailler en R&D. Mais nous pouvons encore apprendre une partie du jargon. Voici une phrase : framework de tests unitaires JSL. Qu'est-ce que c'est? Comment est-ce arrivé? Et pourquoi est-ce important?
Démystifions le framework de tests unitaires JSL.
Merci à Nicole Jones ( @Nicole_Jones ), Sr. Manager of Advanced Analytics Testing, pour cette explication :
"Le terme unité fait référence au plus petit composant testable d'un produit logiciel et la phrase test unitaire est le processus de validation pour s'assurer que les unités fonctionnent comme prévu. La phrase cadre de test unitaire en est venu à faire référence au mécanisme utilisé pour faciliter les tests unitaires automatisés.
Statisticien de recherche principal Joseph Morgan ( @Joseph Morgan ) a introduit ces termes dans JMP lorsqu'il a commencé à travailler en tant que testeur statistique en 2005. (Il travaille maintenant dans le groupe DOE.) L'expérience de Joseph est en génie logiciel et en informatique, ainsi qu'en mathématiques et statistiques discrètes.
« Il a conçu l'ensemble du concept, un cadre de test central », explique Audrey Shull, directrice principale de l'ingénierie de test ( @Audrey_Shull ). « Il a beaucoup de grandes idées, et celle-ci en faisait partie. »
« Une fois qu'il s'est familiarisé avec JMP et JSL, il a pu développer le framework de tests unitaires JSL, en gardant à l'esprit la nature statistique du logiciel », explique Nicole.
Joseph Morgan explique (4:38)
« Boire notre propre champagne »
Un framework de tests unitaires peut être écrit dans d'autres langages, mais quel meilleur outil que notre propre JSL ?
Avec le framework de tests unitaires JSL, « nous utilisons JMP pour tester JMP », explique Audrey. En d'autres termes, nous « buvons notre propre champagne ». Et ce n'est pas possible avec tous les outils.
"Nous pouvons utiliser notre logiciel pour tester notre logiciel car nous avons ce langage JSL polyvalent", poursuit Audrey. « Nous repoussons les limites de ce que JSL peut faire pour prendre en charge le framework. C'est une chose assez spéciale. Et le framework lui-même sert de test de régression énorme pour la compatibilité descendante JSL.
« Si l'équipe de développement modifie le fonctionnement des scripts, le groupe de test le trouve en premier car nous sommes le premier client du langage JSL.
« Toutes les entreprises essaient d'utiliser l'automatisation, mais elles utilisent souvent d'autres outils tiers pour le faire. Ils n'auront pas toujours le luxe d'utiliser leur propre logiciel."
Un cadre extensible
Une capture d'écran de la boîte de dialogue d'origine. Le framework de tests unitaires JSL est utilisé sur toutes les plateformes JMP. Par exemple, il peut être utilisé pour tester la fonctionnalité de glisser-déposer dans Graph Builder. Ou les menus du triangle rouge. Ou n'importe quelle unité de code dans la plate-forme de distribution.
« Non seulement nous pouvons l'utiliser pour tester JSL lui-même, mais nous pouvons également utiliser le framework pour tester toutes les autres plates-formes », explique Audrey.
Nicole précise :
« Au moment où Joseph développait le framework, son objectif principal était de trouver un moyen de créer une suite de tests de régression pour les plates-formes statistiques dans JMP. Pourtant, il a pu créer un cadre extensible – la suite de tests de régression comprend des plates-formes statistiques ainsi que des plates-formes graphiques, elle fonctionne sur Macintosh ainsi que Windows, elle teste les commandes de table de données ainsi que les structures de rapport.
Travailler avec « un filet de sécurité »
Le framework peut être exécuté manuellement - les testeurs et les développeurs peuvent lancer, pointer, cliquer et exécuter. Mais l'automatisation est la clé de l'amélioration continue.
Le framework est automatisé via Perforce (un référentiel de travail), où réside le travail des développeurs, où le code est implémenté. Les testeurs JMP rédigent des cas de test et les téléchargent dans une section dédiée dans Perforce.
Capture d'écran de la boîte de dialogue de test telle qu'elle se présente aujourd'hui.
Un processus automatisé nocturne, exécuté par le développeur de systèmes principal Jim Borek, récupère tous les tests téléchargés ce jour-là, récupère tout le code poussé ce jour-là, exécute les cas de test sur le code mis à jour et avertit l'équipe en cas d'échec. Jim est au cœur de l'automatisation de ce processus et de la maintenance des machines.
Audrey a décrit l'énormité des tests qui ont lieu : 2,4 millions de tests sont exécutés chaque nuit. Et cela se produit sur tous les systèmes d'exploitation (par exemple, Windows, Catalina, BigSur) pour JMP 17 et JMP 16.2. Le processus d'exécution des tests sur une seule machine prend 6 à 10 heures, selon la vitesse à laquelle les machines fonctionnent.
« C'est la suite de tests de régression – sans ce cadre, nous serions obligés de tester ces éléments chaque jour pour voir s'ils se cassent ou non », explique Audrey. « Cela ne peut pas être manuel. La suite de tests est automatisée afin que le système nous avertisse qu'un échec s'est produit.
« Nous aimons parfois appeler cela un filet de sécurité. Je sais que cela a fonctionné la dernière fois que je l'ai testé, j'ai écrit un scénario de test, et s'il tombe en panne, le système me le fait savoir. Je peux passer à autre chose. Nous essayons de tester ce qui est nouveau et à venir et ajouté au logiciel.
Le flux de travail du cadre de test JSL
Trouver un bug Apple
Joseph partage une première anecdote qui a cimenté la valeur du cadre de test unitaire.
« Peu de temps après la mise en œuvre initiale du framework de tests unitaires JSL, sa valeur est devenue dramatiquement apparente d'une manière plutôt inhabituelle. Fait intéressant, ce n'est pas une régression de JMP qu'il a détectée, mais plutôt un élément clé pour isoler un bogue assez grave dans MacOS.
« Au début de 2006, Apple a commencé à faire passer la gamme Macintosh des processeurs PowerPC aux processeurs Intel et, afin de faciliter cette transition, il a fourni un émulateur avec MacOS connu sous le nom de Rosetta. Cet émulateur permettait aux applications PowerPC de fonctionner sur des Mac Intel et était donc considéré comme un logiciel clé par Apple.
« Il s'est avéré qu'il y avait un bogue dans l'émulateur Rosetta qui a conduit à plusieurs anomalies inhabituelles dans le comportement de JMP. Avec le framework de tests unitaires, j'ai pu isoler le problème à un bug dans l'implémentation de la fonction racine carrée dans Rosetta ( voir Défaut S0351925 ).
« Michael Hecht et moi avons eu plusieurs conférences téléphoniques avec des ingénieurs d'Apple pour expliquer le problème, mais les ingénieurs ont insisté sur le fait qu'il s'agissait d'un bogue JMP. Ce n'est que lorsque Michael m'a suggéré d'écrire une application C++ très simple qui imitait essentiellement l'un des tests unitaires qui présentait le bogue qu'Apple était convaincu que le problème était un bogue Rosetta. Un an plus tard, en mars 2007, Apple a publié un correctif pour le bogue Rosetta dans Mac OS X 10.4.8.
A qui profite-t-il ?
« [Le framework] a été développé en pensant aux testeurs, mais s'est également avéré utile pour les développeurs », déclare Nicole. « J'apprécie la capacité de Joseph à créer un cadre qui peut répondre aux besoins de tant d'entre nous.
Les testeurs situés à Cary et Pékin répartissent les fonctions et surveillent certains domaines de JMP. Mais quelle que soit la partie de JMP dont ils sont chargés de tester, tout le monde teste également le langage de script.
Audrey déclare : « Plus nous utilisons JMP et JSL, plus nous pensons à des « bons à posséder ». Même si ce n'est pas nous qui mettons les choses en œuvre, c'est parfois nous qui demandons « pouvez-vous ajouter ceci ou cela ? » »
Et l'amélioration constante, bien sûr, profite aux clients.
« Nos utilisateurs puissants de JSL peuvent vouloir faire certaines des choses que nous faisons. Cela nous incite à réfléchir à la manière dont nous pouvons scénariser de manière plus robuste. »
Beaucoup de cloches et de sifflets qui ont été ajoutés ont été externalisés à partir de l'équipe de développement, de test et d'ingénierie de publication.
Félicitations aux acteurs clés qui ont ajouté des fonctionnalités au fil des ans :
Joseph Morgan @Joseph Morgan
Mélanie Drake @melaniedrake
Jim Borek
Xan Gregg @XanGregg
Michel Hecht @hecht_jmp
Justin Chilton @Justin_Chilton
Evan McCorkle @EvanMcCorkle
Nick Holmes @nickholmes13
Ce n'est qu'un exemple parmi tant d'autres de l'ingéniosité, de la collaboration et de l'engagement de la division JMP en faveur de l'amélioration continue. Nous espérons mettre en évidence d'autres histoires comme celle-ci. Contactez Jessica Marquardt avec des idées.
Vous voulez plus d'informations ?
Tableau de bord de test JMP
Cet article de la lettre d'information sur la R&D en Chine par Nala Sun, responsable de l'ingénierie de test ( @Nala ) a inspiré ce post : Cadre d'automatisation des tests unitaires JSL
Voici comment les résultats des tests unitaires JSL sont générés, traités et utilisés pour les tests unitaires nocturnes : Pipeline de données du framework JSL
Un article de Joseph Morgan : Unité JSL : Tests JSL automatisés
Orso, Alessandro et Gregg Rothermel. « Tests de logiciels : un carnet de voyage de recherche (2000-2014). » Avenir des procédures de génie logiciel. 2014. 117-132.
La page professionnelle d'Alex Orso : https://www.cc.gatech.edu/home/orso/
Et grâce à @shannon_conners pour fournir un contexte et des conseils.
