Conférencier | Transcription |
| Serkay Olmez | Bonjour, c'est Serkay et Fred de Seagate et aujourd'hui nous allons parler de la façon dont nous avons construit un écosystème JSL pour gérer nos scripts JSL. |
| Nous utilisons donc Git pour gérer les contrôles de source, la source de nos scripts JSL, ainsi que pour les distribuer. Ce sera donc le point principal de la discussion d’aujourd’hui. |
| Mais en plus de cela, je parlerai également de l'intégration de VBA pour PowerPoint, ainsi que de la collecte des journaux de crash, ainsi que des tests unitaires. Je vais passer rapidement aux grandes lignes. |
| Donc, ce dont je veux d’abord parler, c’est de notre histoire, celle de JSL. J'écris des scripts en JSL depuis environ 10 ans. |
| Et nous sommes très satisfaits de là où nous en sommes actuellement, mais il nous a fallu pas mal de temps pour en arriver là et je veux parler des étapes de notre expérience, de ce que nous avons fait jusqu'à présent et pourquoi nous l'avons fait. |
| Et puis nous parlerons de Git et de la manière dont nous avons permis à Git de contrôler les sources de nos scripts JSL et de la manière dont cela nous a permis de créer d'autres fonctionnalités. Par exemple, une fois que vous avez activé Git, |
| vous pouvez ajouter plus de fonctionnalités telles que la surveillance de vos scripts. Vous savez donc que les développeurs peuvent savoir que leurs scripts sont en cours d'utilisation, afin de pouvoir en surveiller l'utilisation. |
| Et probablement plus important encore, ils peuvent également collecter des journaux. Si le script plante, le développeur le sait et il peut revenir en arrière et corriger ces bugs. Et tu peux... |
| vous pouvez ajouter une fonctionnalité supplémentaire pour aller plus loin. Vous pouvez même créer des tickets de bug automatisés si vous savez déjà que votre script a planté. Vous pouvez donc créer automatiquement un ticket de bug pour cela. Et vous pouvez suivre ces tickets à l'aide d'un logiciel de suivi tel que JIRA ou Atlassian. |
| Et je terminerai avec nos meilleures pratiques et les leçons apprises jusqu'à présent. |
| Donc, |
| Et en annexe, j'ai aussi un manuel pour un script dont je vais parler. C'est un script qui peut transférer des images vers PowerPoint. |
| Et j'ai un manuel très détaillé pour cela, et je dois juste vous faire savoir que tout ce dont je parle ici, les données et les scripts seront disponibles. |
| Et ils sont publiés dans un référentiel public dans la section références ici et vous pouvez simplement y aller et récupérer ces fichiers si vous choisissez de le faire. Alors laissez-moi commencer par |
| avec le bref historique ici. Donc 10... Je travaille avec JSL depuis environ 10 ans, et j'ai commencé, j'ai commencé avec |
| très basiques et je ne connaissais pas vraiment grand-chose aux scripts JSL. |
| Et puis, une fois que vous avez commencé à faire cela, vous réalisez que vous devez avoir un contrôle de source approprié et que vous avez besoin de moyens appropriés pour distribuer vos scripts. |
| Le problème avec les scripts JMP, c'est qu'ils n'ont aucune barrière à l'entrée. Vous pouvez donc littéralement créer un tracé manuellement, puis récupérer le script. C'est écrit pour vous. |
| Et vous pouvez également utiliser Community to JMP sur JMP.com pour poser des questions et obtenir des réponses. |
| Et vous... le script est si efficace que vous faites votre travail si efficacement et les gens le remarqueront. Ils vous demanderont comment vous faites les choses et vous direz que j'ai un script pour cela. Et ils le feront |
| demandez : « Pouvez-vous partager cela avec moi ? Et tout d’un coup, vous devenez développeur, alors que vous n’en aviez pas l’intention. |
| Et puis vous devez vous occuper de la distribution de vos scripts. La première idée qui me vient à l'esprit est de simplement les attacher, ce qui est une idée horrible, et je fais cela depuis un bon moment. |
| Et il est assez évident pourquoi ce n'est pas une bonne idée, parce que vous joignez un script, puis vous l'envoyez et le lendemain, vous faites un |
| révision et vous devez ensuite la renvoyer, et vous ne savez même pas si l'utilisateur optera pour la suivante. J'illustre donc simplement ce point ici. |
| Récemment, j'ai reçu un e-mail d'un collègue et il faisait référence à un script que j'ai créé en 2017 et je numérotais juste mes scripts avec ceux-ci. |
| numéros de version, ce qui n'est pas une bonne idée. Cela revient donc après trois, quatre ans et vous réalisez que les gens utilisent toujours des scripts vieux de trois ans, parce qu'ils n'ont pas été mis à jour. |
| Une façon de résoudre ce problème consiste à utiliser un lecteur partagé et, en fonction de l'interaction que j'ai eue avec les personnes qui s'y trouvent dans le |
| Discovery Summits, c'est que de nombreuses personnes, de nombreuses entreprises utilisent celui-ci. Alors, ce que font les développeurs, c'est |
| transférez leurs scripts dans un lecteur partagé et les utilisateurs les extrairont directement du lecteur partagé, ce qui résout la moitié du problème de distribution, mais cela ne fait rien en matière de contrôle des sources. Vous ne... vous ne pouvez pas retracer les modifications que vous avez apportées au code. |
| Et c’est pourquoi nous avons migré vers Git. Et cela a été une avancée majeure pour nous et a permis de nombreuses fonctionnalités. Alors, que faites-vous avec Git, c'est que les développeurs poussent leurs scripts vers un référentiel et |
| les utilisateurs extrairont leurs scripts directement de Git. C'était donc une grande amélioration pour nous et cela nous a permis de collecter des journaux de crash et |
| utilisation des scripts, etc. Et je veux juste parler de quelques autres choses que j'ai apprises lors des sommets. Ils ont été très utiles pour améliorer mes compétences en matière de script et j'ai assisté à un sommet en 2018 et j'ai beaucoup appris sur les expressions, etc. |
| les gens voudront peut-être revenir en arrière et écouter ces présentations, car elles les aident à développer leurs compétences en matière de script. |
| Et une autre étape importante pour nous concernait les tests. J'ai donc été inspiré par cette conférence du Summit de l'année dernière, qui portait sur les tests unitaires et qui vous permet de tester automatiquement vos scripts avant de les publier. |
| Aujourd'hui, je parlerai principalement des tests d'intégration car les tests unitaires sont... des tests unitaires sont obligatoires, mais pas suffisants. |
| Parce que vous pouvez faire un test unitaire, vous pouvez tester tous vos modules et ils fonctionnent correctement. Mais une fois assemblés, ils ne fonctionneront pas. Ils vont s'écraser, comme illustré ici. Chaque tiroir est probablement testé, mais lorsque vous les assemblez, ils ne fonctionnent pas. |
| Une fonctionnalité intéressante qui aide beaucoup le développeur concerne la collecte de journaux. |
| Il est très utile de savoir que votre script s'est écrasé et, vous savez, comment il s'est écrasé. Et vous pouvez le faire en collectant les journaux des utilisateurs et vous pouvez revenir en arrière et corriger votre script et appliquer les modifications, et les utilisateurs auront immédiatement leur script corrigé. |
| Et la dernière fonctionnalité que nous déployons assez récemment concerne le rapport automatisé de bogues. Puisque vous disposez déjà du rapport d’accident, pourquoi ne pas agir en fonction de ces informations ? Et donc nous créons un système automatisé |
| surveillance |
| système, qui suivra ces journaux de crash et créera automatiquement des rapports de bogues afin que le développeur puisse travailler dessus. Et en plus de cela, vous pouvez ajouter l'utilisateur en tant qu'observateur afin qu'il sache que quelqu'un travaille sur le problème. Voilà, c'est ça qui résout le problème |
| cela résout le manque d’informations entre l’utilisateur et le développeur. |
| Cela montre donc la chronologie et je vais passer du temps sur le |
| sur les éléments individuels, mais nous commencerons par Git et je vais construire cela rapidement et laisser Fred en parler. |
| 163084 | D'accord. |
| Donc, |
| Git n'est qu'un système de contrôle de version, et je n'utilise pas le mot contrôle de version. En fait, je tiens à dire que Git vous aide en vous offrant effectivement une restauration illimitée, même si vous utilisez Git uniquement sur votre propre ordinateur local. Il |
| vous donne la possibilité de suivre les révisions de vos fichiers et de revenir aux anciens, au cas où vous décideriez qu'un travail que vous avez effectué au cours des dernières semaines était incorrect et que vous voudriez revenir à quelque chose d'il y a plusieurs semaines. |
| Git n'est donc qu'un logiciel que vous installez sur votre ordinateur local. Il crée un référentiel, et ce référentiel peut ensuite être publié dans d'autres référentiels. |
| Comme GitLab ou GitHub. TortoiseGit est une interface graphique à installer sur votre machine locale qui facilite les choses. Alors si, Serkay, si vous pouviez ouvrir la diapositive suivante. |
| Le modèle que j'ai essayé de faire utiliser aux développeurs se trouve donc sur leur ordinateur local. Les développeurs en local, demandez-leur d'installer le client Git et de démarrer |
| version contrôlant les fichiers sur leur PC local. Une fois qu'ils auront pris l'habitude de faire cela, nous pourrons les connecter à un référentiel distant. |
| et Git se connecte à des référentiels distants ou à SSH en général ou à d'autres méthodes et ils peuvent pousser |
| des copies de leur base de données Git jusqu'au référentiel distant. Une fois qu'il est installé sur le référentiel distant, il est alors disponible pour qu'un serveur Web HTTP puisse le partager et JMP. |
| peut ensuite pointer vers les URL et le serveur Web HTTP...HTTP et charger des scripts à partir de celui-ci. Ainsi, au lieu d'utiliser un lecteur partagé, nous utilisons un serveur Web HTTP qui a été alimenté par un push vers un référentiel Git. |
| Et puis les puces ci-dessous soulignent simplement les avantages de cela et comment cela fonctionne exactement. |
| Nous pouvons passer à la diapositive suivante. |
| Serkay Olmez | Je vais donc prendre le relais ici, Fred, et je vais vous montrer... une implémentation d'illustration très basique, et les scripts sont disponibles dans les références. |
| Donc, |
| ce sera un code très basique. Et ce que je montre ici, c'est le code que le développeur développe. C’est son strict minimum, n’est-ce pas. C'est juste une boîte de dialogue qui dit bonjour tout le monde. |
| Et supposons que le développeur souhaite transmettre ce code aux utilisateurs. Donc au lieu de donner ce code, le développeur transmet ce code, |
| qui est un lien vers le référentiel. Voici donc le référentiel du script hello JSL qui y réside... |
| dans le référentiel distant. Ce que fait l'utilisateur, c'est qu'il saisit... l'utilisateur saisit le |
| script à partir de l'URL. C'est donc du code statique. Il ne nécessite aucune modification, le développeur peut donc modifier le script quand il le souhaite, mais l'utilisateur n'a rien à faire. Et je vais juste vous montrer une illustration ici et je veux juste passer en plein écran. |
| Illustre simplement comment cette chose fonctionne avec une interface graphique particulière, à savoir GitHub Desktop. Alors ce que vous faites, c'est installer ceci |
| logiciel sur votre ordinateur et créez un référentiel local, et ils garderont une trace des modifications que vous avez apportées. Par exemple, dans ce cas, je viens de créer ce script hello JSL |
| et ce logiciel saura qu'il y a un changement et il le mettra automatiquement en évidence. Et ce que vous faites, c'est que vous le validez d'abord dans votre référentiel local, |
| qui pousse ces éléments dans votre dépôt local, puis vous les pousserez vers l'origine, qui est un référentiel distant. Maintenant, je vais le pousser vers la télécommande qui le rendra disponible aux utilisateurs. |
| Donc, une fois que vous aurez fait cela, les utilisateurs pourront désormais extraire ce nouveau code. Et je reviens maintenant au rôle d'utilisateur ici et c'est le script, l'utilisateur exécute, et quand... une fois que vous aurez fait cela, la boîte de dialogue apparaîtra. Vous exécutez donc le script que vous avez extrait du référentiel. |
| Je vais donc illustrer... illustrer cela un peu mieux avec un code plus avancé, qui sera également lié à PowerPoint. |
| Les gens effectuent donc beaucoup d’analyses dans JMP et, en fin de compte, nombreux sont ceux qui souhaitent encore transférer leurs résultats dans PowerPoint. Je sais que JMP a certaines capacités à pousser |
| images directement sur PowerPoint, mais nous voulions un peu plus... quelque chose d'un peu plus sophistiqué. Nous voulons |
| gérer le modèle du PowerPoint. Nous voulons faire encore plus de choses dans PowerPoint, décider combien d'images nous voulons mettre par diapositive, etc. |
| pour ce faire, vous devez d'abord connecter JMP à PowerPoint et vous pouvez le faire en fait très... |
| d'une très bonne manière pour que vous n'ayez même pas besoin de quitter JMP. Donc, ce que vous pouvez faire, c'est localiser l'emplacement de votre fichier exécutable PowerPoint, et il se trouve généralement sous Program Files. |
| Et puis vous créez un fichier batch qui déclenchera cet exécutable PowerPoint, et il ira récupérer le fichier PowerPoint que vous souhaitez exécuter et il l'exécutera simplement. Vous pouvez donc faire tout cela dans JMP. Fondamentalement, cela recherche le fichier exécutable PowerPoint. |
| Et une fois qu'il l'a localisé, il le regroupe dans ce fichier batch. Et il inclut également le chemin d'accès au PowerPoint que vous souhaitez exécuter |
| et la macro et donc le PowerPoint contiendra une macro pour effectuer la gestion dans le PowerPoint. Alors c'est comme ça que tu |
| associez JMP à PowerPoint et vous devrez même laisser JMP faire cela. Mais la question est de savoir comment transmettre ce fichier PowerPoint à vos utilisateurs pour commencer ? Vous pourriez |
| demandez-lui d'aller le télécharger, ce qui n'est pas idéal car vous souhaitez gérer cela automatiquement et en même temps vous souhaitez également contrôler la source de votre PowerPoint. Il faut donc que ce soit un bon candidat ; il doit constituer une bonne partie de l’ensemble de l’écosystème. Vous ne voulez pas le mettre dehors. |
| Et une autre condition est que vous ne souhaitiez pas télécharger PowerPoint à chaque exécution du script. Vous souhaitez donc télécharger le PowerPoint uniquement s'il a changé dans ce référentiel d'images ou s'il y a quelque chose de nouveau avec PowerPoint. |
| Donc, une façon de faire cela est d'utiliser ce petit script JMP, une commande JMP qui correspond à la date de création. Donc ce que je fais ici, c'est vérifier |
| la date du fichier local. Donc, si le PowerPoint local est plus ancien que celui que j'ai dans le référentiel, je vais le télécharger. Donc |
| il ira télécharger le PowerPoint à l'aide d'une requête HTTP, et il |
| ça ressemble à quelque chose comme ça. Donc, ce que vous faites, c'est simplement d'aller vérifier votre PowerPoint sur votre ordinateur local. S'il n'existe pas, vous pouvez simplement l'extraire du référentiel à l'aide d'une requête HTTP. S'il existe, on aime regarder sa date, et s'il est vieux, on y va quand même |
| tirez le nouveau. L'essentiel ici est donc que vous pouvez intégrer PowerPoint de manière transparente dans l'environnement JMP, afin de pouvoir transférer vos résultats dans JMP, y compris les tableaux et les images. Et vous pouvez faire tout cela sans rompre le contrôle des sources et je vais vous montrer une démonstration ici. |
| Ce sera donc le code, par exemple, que vous donneriez à vos utilisateurs. Encore une fois, c'est du code statique. Il n'a vraiment rien à part une URL, qui relie le script au référentiel distant. Alors il ira chercher le |
| Le script JMP du référentiel et ces scripts sont à nouveau disponibles et vous pouvez simplement les extraire des références. |
| Du côté du développeur, c'est le véritable script, n'est-ce pas. Ceci est le script, le développeur a développé et |
| il ou elle le pousse vers un référentiel distant. Et la bonne chose à propos de ce script est que je veux juste souligner rapidement quelques fonctionnalités ici. |
| Donc si, par exemple, regardez ceci. Il s'agit d'un script de texte autonome et vous n'avez pas besoin de distribuer des fichiers PowerPoint ou des scripts supplémentaires. |
| séparément. Ce que vous faites, c'est les lier dans votre script et ils sont liés dans le référentiel ici, |
| y compris le PowerPoint. Ce script gérera donc toute la distribution. Donc, il ira récupérer le PowerPoint. |
| Il ira récupérer d'autres fichiers supplémentaires si nécessaire. Ainsi, tout est regroupé dans le script, ce qui fait toute la gestion pour vous. Alors laissez-moi vous montrer cela rapidement. Je vais retirer ça |
| et je le mets en plein écran |
| pour que vous puissiez voir clairement. Ce sera donc une démonstration du déclenchement automatique de PowerPoint |
| pour cela pour un cas particulier. Et ce que fait ce script, c'est qu'il récupère les chemins de la table, c'est une table JMP qui comprend de nombreux chemins d'images, et ceux-ci font référence à ce point particulier. |
| serveur, et il empruntera ces chemins et il prendra simplement ceux en surbrillance ici et il les poussera dans PowerPoint. |
| Je vais juste l'exécuter et ce script est à votre disposition si vous souhaitez l'essayer. Et c'est un script utile entièrement fonctionnel. Donc, et je dirige ça |
| script ici. Encore une fois, il s'agit du référentiel. Il n'a donc pas le script de ligne, il le extrait simplement du référentiel. Vous l'exécutez, il récupère le code, lance un dialogue. |
| Et je vais simplement exécuter ceci. Je n'entrerai pas dans les détails, et une fois que vous l'aurez exécuté, il déclenchera automatiquement PowerPoint. |
| Et PowerPoint va se lancer et puis... ça commence... ça construit les diapositives ici. Il extraira 20 images et cela prendra 10 ou 20 secondes et vous aurez ensuite le PowerPoint |
| fait. Voici donc le PowerPoint que vous obtenez et tout se fait automatiquement et tout a été extrait du référentiel. |
| Alors, quelle est la prochaine étape ? Comment réviseriez-vous ce PowerPoint ? Donc, je suppose que vous souhaitez apporter des modifications à votre modèle. Et |
| vous pouvez voir plus de détails à ce sujet dans l'annexe, mais ce que je veux montrer, c'est comment vous modifiez le |
| script dans PowerPoint. Et j'irai en plein écran, |
| et je vais juste exécuter ça. Ce dont nous partons est ce qui nous reste dans la diapositive précédente, à droite, donc vous aviez ces images. |
| Ce que je veux faire, c'est changer le modèle de manière triviale, pour illustrer simplement ce point. Alors tu vas à... |
| vous allez à la macro, vous faites défiler vers le bas et trouvez la chose que vous souhaitez modifier, et je vais faire un simple changement ici. Je vais changer la couleur de l'en-tête juste pour faire valoir un point, n'est-ce pas. Alors tu changes ça |
| et |
| sauvegarde le. Et ça se passe en temps réel. |
| Vous enregistrez ceci et pouvez supprimer les diapositives afin qu'elles soient transférées plus rapidement vers le référentiel, car vous les transférerez vers le référentiel. |
| Et puis vous diffusez cela en utilisant l'interface graphique de Git. Il ira dans le dépôt |
| et il le mettra à la disposition de vos utilisateurs. Ainsi, tous vos utilisateurs recevront la modification instantanément. Donc, pour que vous n'ayez pas besoin de leur demander d'aller mettre à jour le PowerPoint ou quoi que ce soit. |
| Cela va simplement au référentiel. |
| Et je vais revenir à JMP et en mode utilisateur, puis réexécuter le script, qui récupérera le nouveau PowerPoint. |
| Et si vous l'exécutez à nouveau, il passera par le |
| diapositives, cela créera la diapositive. Et ce que vous remarquerez, c'est que vous avez apporté des changements, qui concernaient le changement de la couleur de la ligne d'en-tête. |
| Donc, |
| Qu'avons-nous d'autre? |
| Surveillance des scripts. Je pense que c'est l'une des meilleures fonctionnalités que nous avons développées, car elle donne la possibilité au développeur de voir si |
| leur scénario...le sien, son scénario est apprécié ou pas. Droite. Alors, c'est couru ? Est-ce que quelqu'un le gère régulièrement ? |
| C'est donc un avantage. L'autre avantage concerne |
| log...collection de journaux de crash. Ainsi, si le script échoue, vous pouvez capturer l'échec à l'aide de cette fonctionnalité de capture de journal de JMP. Vous prenez donc en sandwich vos sous-programmes dans la capture de journaux. |
| S'il échoue... l'échec... le journal de l'échec sera renvoyé dans ce journal en texte renvoyé. Et puis ce que tu fais aussi, c'est toi |
| joignez-le dans un essai, afin que le script survive toujours pour faire le rapport. |
| Et puis vous vérifiez s'il est vide. S'il est vide, cela signifie qu'il n'y a eu aucun crash et que vos scripts ont donc survécu. |
| Mais si ce n'est pas le cas, s'il n'est pas vide, cela signifie qu'il y a eu un crash et que vous l'avez contenu. Vous pouvez récupérer le journal et maintenant vous pouvez le signaler. Et la façon de le faire est d'utiliser HTTP |
| l'ID utilisateur, le nom du script et la note de journal, qu'il s'agisse d'un crash... |
| qu'il s'agisse d'un crash ou simplement d'une exécution régulière, peut-être de quelques mesures de performances. En fin de compte, vous pouvez donc transmettre certaines métadonnées de données concernant votre script au développeur. |
| Et ce que le serveur fera, c'est les enregistrer et vous aurez un ensemble de fichiers stockés sur le serveur et vous pourrez les surveiller. Et je montre juste un échantillon |
| table hors de ceux-ci. C'est un journal de crash, qui a... qui a la date, il a un nom de script, donc ce script a échoué à la date |
| avec cet accident particulier. C'est donc extrêmement utile pour le développeur car il peut revenir en arrière et résoudre le problème. Je vais donc réduire ceci et cela et je ferai ici une démonstration rapide qui montre comment vous |
| comment tu |
| contenir le crash et comment vous le signalez à l'utilisateur. Donc, ce que je vais faire ici, c'est faire planter un sous-programme. Je vais créer un paramètre non défini |
| et JMP se plaindra. Il dira que cette chose n'est pas définie, donc le script plante. Mais ce que je vais faire, c'est appeler ce sous-programme |
| dans une fonctionnalité de capture de journal et tout sera pris en sandwich en cours d'essai. Ainsi, même si le script plante avec le sous-programme, il survivra globalement et pourra signaler un problème. |
| rapport d'accident. Alors, donnez-lui une notification bien formatée à l'utilisateur et dites-le. Ainsi, les scripts plantent avec cette erreur particulière et nous avons créé un journal pour cela et nous y travaillons. Voilà donc la notification que vous leur donnez... à l'utilisateur. |
| L’une des choses clés que j’ai apprises lors des sommets concerne les tests automatisés. Donc moi, je faisais mes tests manuellement, ce qui est très frustrant. |
| Parce que cela prend du temps et que vous ne pouvez pas capturer chaque recoin de votre script. C'est impossible de faire des heures de tests quand on fait un petit changement. |
| J'ai donc commencé à me lancer dans les tests automatisés et il est très important de faire des tests unitaires. Donc, vous savez, les tests font référence au test de sous-programmes individuels. Vous avez donc une fonction et vous souhaitez la tester |
| plusieurs fois avant de l'intégrer dans votre système global, afin que vous puissiez effectuer ces tests unitaires |
| pour des modules individuels, mais cela ne suffira pas. Et je peux vous en montrer quelques exemples. |
| Par exemple, la NASA a perdu son Mars Climate Orbiter pour une raison très étrange... à cause d'une erreur très étrange, car il y avait deux équipes de logiciels, une en Europe, |
| un aux États-Unis. Et l'un d'eux travaillait avec les unités en livres et celui aux, oui, c'était celui aux États-Unis et celui en Europe. |
| utilisait Newtons. Ils ont donc certainement fait leurs tests unitaires. Mais quand ils ont élaboré leur code, cela n’a pas fonctionné, car l’un attendait des Newtons et l’autre prenait des kilos. Alors ils ont littéralement perdu le |
| Orbiter, simplement parce qu'ils ont oublié de convertir les livres en Newtons. Et plus récemment, en tant que Starliner, Boeing a perdu son Starliner, puis ils ont admis qu'ils auraient pu détecter l'erreur s'ils l'avaient fait. |
| un test d'intégration rigoureux. Et en fin de compte, ce qui compte, c'est le |
| test d'intégration car les modules ne vivent pas seuls dans le script, ils parlent ensemble. |
| Et c’est une drôle d’illustration du problème ici. Vous pouvez ainsi disposer de deux objets qui sont testés minutieusement. C'est une fenêtre, n'est-ce pas, qu'est-ce qui peut mal se passer avec une fenêtre ? |
| Mais si vous en avez deux assemblés, ils ne s'ouvriront même pas, vous devrez donc faire quelques tests d'intégration pour voir s'ils sont combinés, s'ils fonctionnent bien ensemble. |
| Et je veux illustrer ici un point rapide qui montre comment j'ai commencé à faire des tests automatisés. Et cela fera référence à un cas particulier, qui est |
| un cas difficile, pour être honnête, car il s'agira de tester une fenêtre modale et les fenêtres modales ne disparaîtront pas à moins que vous ne cliquiez sur un bouton. Donc tu dois |
| créer un script JMP qui clique sur un bouton, qui imite en quelque sorte un comportement humain, et ce que je fais ici, c'est injecter un testeur dans le |
| fenêtre modale ici. Et ce qui est bien avec cette approche, je pense, c'est que vous pouvez toujours distribuer |
| cette chose, ce script à vos utilisateurs et les utilisateurs ne se rendront même pas compte qu'il contient en fait une routine de test. |
| Il a donc les hooks pour un testeur, mais ensuite vous l'exécutez seul, ce qu'il fait, c'est qu'il recherche ce paramètre de mode test et il n'est pas défini. |
| Donc, s'il n'est pas défini, le script le mettra à zéro, ce qui désactivera tous les hooks de la table. Vous pouvez donc le donner à vos utilisateurs et ils peuvent l'exécuter ainsi. |
| Cependant, si vous souhaitez tester votre script, vous devez créer un code de testeur par-dessus. Ainsi, le code du testeur définira le mode de test sur un et créera également le testeur... |
| objet testeur que vous souhaitez injecter dans votre script. Par exemple, dans ce cas particulier, ce qu'il fait, c'est sélectionner une colonne particulière |
| puis il lui attribue un rôle en cliquant sur un bouton, puis il exécute le script, n'est-ce pas. Cela imite littéralement un comportement humain. |
| Ensuite, il chargera le script lui-même. Il s'agit donc essentiellement d'injecter ces paramètres dans le script que vous souhaitez tester. Maintenant, vous exécutez le script automatiquement, il chargera donc le script et l'exécutera, et fermera l'interface utilisateur après avoir cliqué sur ce bouton et ce bouton. |
| Et puis, ce que vous faites, c'est de l'exécuter à nouveau dans une fonctionnalité de capture de journal, afin que vous sachiez que si quelque chose ne va pas, vous capturerez l'échec. |
| Et vous le mettez également dans l'essai d'entrée pour que dans l'ensemble, le script survit pour signaler le journal. Et puis, si tout va bien, vous aurez un retour de journal vide, ce qui signifie que votre script n'a pas échoué. |
| Si quelque chose ne va pas, vous le saurez dans la capture du journal. Voilà donc l'idée. |
| Donc, |
| Nous avons |
| la possibilité de surveiller les scripts. Nous avons la capacité de |
| capturer les journaux des accidents. Nous nous sommes donc demandé pourquoi, pourquoi ne pas agir sur le journal des crashs ? Si vous voyez un journal de crash qui signifie que quelque chose s'est mal passé, et un script qui... l'utilisateur le sait déjà parce que le script s'est écrasé, évidemment, et le développeur sait que le script s'est écrasé parce que les journaux sont |
| stocké sur un serveur. Ils sont donc là pour que vous puissiez agir. Mais le fait est qu’il ne s’agit pas encore d’une boucle fermée, car l’utilisateur ne sait pas que le développeur le sait. Et vous pouvez boucler cette boucle en créant des tickets automatisés. Puisque vous disposez déjà des informations, vous pouvez |
| utilisez un logiciel de suivi de bugs tel que JIRA Atlassian et vous pourrez ensuite utiliser la fonctionnalité REST |
| pour collecter les informations du serveur, créez un ticket, attribuez-le au développeur et vous pouvez également affecter l'utilisateur en tant qu'observateur. L'observateur signifie que chaque fois que le développeur fait quelque chose |
| à propos du bogue et saisit ces informations dans JIRA, qui seront renvoyées à l'utilisateur afin qu'il soit averti et sache que quelqu'un travaille sur le bogue. |
| Et il existe plusieurs façons de le faire, selon la version de JIRA que vous possédez, et je vous donne juste le |
| code de base ici. C'est un code curl que vous pouvez créer et vous collectez les métadonnées que vous avez à partir des journaux de crash et vous les intégrez dans un fichier JSL, puis il sera transmis via REST et ira dans le |
| JIRA, qui est... qui le suivra pour vous. Et puis JIRA le fera, si vous configurez correctement, JIRA le notifiera... JIRA informera le développeur et éventuellement |
| l'utilisateur pour lequel...pour qui le script s'est écrasé. Et donc tout est lié et le développeur saura qu'il y a un bug sur lequel il doit travailler et l'utilisateur saura que quelqu'un travaillera sur le bug. |
| D'accord. Je pense que cela m'amène à mes notes finales. Ce ne sont que les points à retenir que vous pouvez retirer de cette présentation. |
| Git a été la pierre angulaire de notre système et il nous a permis de créer de nombreuses fonctionnalités intéressantes et je n'ai même pas mentionné les fonctionnalités de base, qui |
| ce qui est assez évident, car cela vous donne également la possibilité de collaborer. Donc, si vous êtes plusieurs personnes travaillant sur le même script. Vous pouvez utiliser toutes les fonctionnalités du |
