Énoncer l'évidence : Nous ne pouvons pas tous travailler en R&D. Mais nous pouvons encore apprendre une partie du jargon. Voici une phrase : cadre de test unitaire 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é désigne le plus petit composant testable d'un produit logiciel et la phrase tests unitaires 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 à désigner le mécanisme utilisé pour faciliter les tests unitaires automatisés.
Statisticien de recherche principal Joseph Morgan ( @Joseph Morgan ) a présenté ces termes à JMP lorsqu'il a commencé à travailler comme testeur statistique en 2005. (Il travaille maintenant dans le groupe DOE.) Joseph a une formation en génie logiciel et en informatique, ainsi qu'en mathématiques discrètes et en statistiques.
"Il a conçu l'ensemble du concept, un cadre de test central", explique Audrey Shull, Sr. Manager of Test Engineering ( @Audrey_Shul ). "Il a beaucoup de grandes idées, et celle-ci en était une."
« Une fois qu'il s'est familiarisé avec JMP et JSL, il a pu développer le cadre de test unitaire JSL, en gardant à l'esprit la nature statistique du logiciel », explique Nicole.
Joseph Morgan explique (4:38)
'Boire notre propre champagne'
Un framework de test unitaire 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 d'énorme test de régression pour la rétrocompatibilité 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
A screenshot of the original dialog.Une capture d'écran de la boîte de dialogue d'origine. L'infrastructure de test unitaire JSL est utilisée sur toutes les plates-formes 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 cadre, 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 de statistiques ainsi que des plates-formes graphiques, elle fonctionne sur Macintosh ainsi que sur 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 et 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ù vit le travail des développeurs, où le code est implémenté. Les testeurs JMP rédigent des scénarios de test et les téléchargent dans une section dédiée de Perforce.
Screenshot of the testing dialog as it looks today.Capture d'écran de la boîte de dialogue de test telle qu'elle apparaît aujourd'hui.
Un processus automatisé nocturne, exécuté par le développeur système 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 informe 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 aurions à tester ces choses tous les jours pour voir si elles se cassent ou non", explique Audrey. « Ça 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 cas de test et s'il casse, 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 bogue 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 évidente d'une manière plutôt inhabituelle. Fait intéressant, ce n'était pas une régression de JMP qu'il a détectée, mais plutôt, c'était la clé pour isoler un bogue assez sérieux dans MacOS.
« Au début de 2006, Apple a commencé à faire passer la ligne 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 s'exécuter sur les Mac Intel et était donc considéré comme un logiciel clé par Apple.
« Il s'avère qu'un bogue dans l'émulateur Rosetta a entraîné plusieurs anomalies inhabituelles dans le comportement de JMP. Avec le framework de test unitaire, j'ai pu isoler le problème d'un bogue 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 les ingénieurs d'Apple pour expliquer le problème, mais les ingénieurs étaient catégoriques 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 présentant le bogue qu'Apple était convaincu que le problème était un bogue de Rosetta. Un an plus tard, en mars 2007, Apple a publié un correctif pour le bogue Rosetta dans Mac OS X 10.4.8.
Qui en profite ?
"[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 d'un si grand nombre d'entre nous."
Des testeurs situés à Cary et à Pékin se répartissent les fonctions et surveillent certains domaines de JMP. Mais quelle que soit la partie de JMP qu'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 'bien-avoir'. Même si nous ne sommes pas ceux qui implémentent les choses, nous sommes parfois ceux qui demandent 'pouvez-vous s'il vous plaît ajouter ceci ou cela ?'
Et l'amélioration constante, bien sûr, profite aux clients.
“Nos utilisateurs JSL expérimentés voudront peut-être faire certaines des choses que nous faisons. Cela nous incite à réfléchir à la manière dont nous pouvons écrire des scripts de manière plus robuste. »
Beaucoup de cloches et de sifflets qui ont été ajoutés ont été externalisés auprès 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 @Melanie_J_Drake
Jim Borek
Xan Gregg @XanGregg
Michel Hecht @hecht_jmp
Justin Chilton @Justin_Chilton
Evan McCorkle @EvanMcCorkle
Nick Holmes @nickholmes13
Ce n'est là qu'un exemple parmi tant d'autres de l'ingéniosité, de la collaboration et de l'engagement de la division JMP envers l'amélioration continue. Nous espérons mettre en lumière d'autres histoires comme celle-ci. Contactez Jessica Marquardt avec des idées.
Vous voulez plus d'informations ?
Tableau de bord des tests JMP
Cet article du bulletin d'information sur la R&D en Chine par Nala Sun, responsable de l'ingénierie des tests ( @Nala ) a inspiré cet article : 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 cadre 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 merci à @shannon_conners pour fournir des renseignements généraux et des conseils.
