Réflexions sur ThoughtWorks Radar 4

Le radar ThoughtWorks 2024 est sorti (vous pouvez télécharger le PDF en 1 clic, aucune inscription fastidieuse n'est requise). Voici 2 choses :

1. moi couvrant des choses qui me semblent confuses sur les tests de composants
2. de nouveaux outils sympas pour enquêter ou comprendre pourquoi ils passent de « Évaluer » à « Adopter »

Si vous voulez juste en savoir plus sur les nouveautés intéressantes à regarder, ignorez mon diatribe sur les tests de composants.

Test des composants : adopter

J'ai plein de questions sur ce « Adopter ». Mon employeur actuel a investi beaucoup de formation et d'outils pour aider les équipes à effectuer des tests de composants, ce que j'adore. Ce que je n’aime pas, c’est une autre technique de test dont la définition diffère selon la personne qui en parle.

Laissez-moi décrire les quelques définitions que j'ai vues dans la nature dans l'ordre chronologique que j'ai appris à leur sujet, avec ce que je _pense_ que la définition de ThoughtWorks est la dernière :

• Storybook pour aider à tester les composants React de manière isolée, largement utilisé par les auteurs de framework de composants
• tester les composants dans un environnement de navigateur isolé à l'aide des tests de composants de Cypress
• Ma dernière définition de Cypress Whitebox Testing, ce qui signifie que tous les appels d'E/S externes (fetch/xhr, chargement de JSON, lecture du stockage local, etc.) sont cy.interceptés ou stubbés/moqués

Rien de tout cela n’est pareil. Un composant dans les contextes ci-dessus signifie en quelque sorte un composant d'interface utilisateur, soit quelque chose comme a ou a qui compose de nombreux autres composants, code et CSS. Je dis « en quelque sorte », car dans Storybook et Cypress, vous utilisez un vrai navigateur, pas un faux comme JSDom. Dans ce contexte, je pense que l'utilisation d'un vrai navigateur peut résoudre de nombreux problèmes, en particulier autour des tests d'acceptation, et non des tests unitaires. J'ai les expériences opposées à ce qu'ils citent : vous pouvez rendre Cypress/Playwright extrêmement rapide (en utilisant des choses comme ça, uniquement, un stubbing lourd, en concevant votre interface utilisateur pour qu'elle soit plus découplée pour tester des flux d'utilisateurs spécifiques), et le montant La confiance que j'ai dans le fonctionnement de l'application, pour l'utilisateur, est extrêmement élevée. Compte tenu du système de typage d'Elm, c'est le principal moyen de valider l'absence de conditions de concurrence dans votre code Elm, et c'est bien car vous pouvez passer plus de temps à écrire des tests d'acceptation en utilisant cette technologie. Les tests Cypress Whitebox ne sont PAS floconneux ; ils sont déterministes, c’est pourquoi nous les aimons tous.

Cependant, je reconnais que le débogage peut être difficile. Le simple fait d'être « dans un navigateur » ne vous donne pas toujours un aperçu détaillé des raisons pour lesquelles quelque chose s'est cassé malgré les points d'arrêt, les mots-clés du débogueur, le code source compilé, un aperçu des appels réseau et divers journaux à votre disposition (pas ironique). , même avec tout ça, tu peux toujours te dire « mec, pourquoi ça ne marche pas… »)

Ensuite, ThoughtWorks et Cypress citent des tests « de bout en bout ». Les définitions ici sont également confuses. Voici quelques définitions que j’ai vues :

• La prise e2e de Dave Farley, qui consiste essentiellement à valider « toutes les choses » fonctionnent ensemble (à ne pas confondre avec une poussée pour les premiers tests All Up)
• Test Blackbox de Cypress, où vous ne stub/simulez PAS les appels ajax et autres E/S, et cela teste simplement « votre site et ses intégrations »
• ThoughtWorks semble dire que Playwright/Cypress/Selenium sont principalement des outils e2e que je considère comme des outils de test d'acceptation, à l'exclusion de la fonctionnalité Cypress Component Testing qui reflète un peu Storybook
• Hillel Wayne les appelle comme ça aussi

Enfin, je n’ai jamais apprécié les extensions de test de composants de React. Ils sont fortement infestés de simulations/d'effets secondaires et vous encouragent fortement à utiliser des compétences JQuery pour valider « Mon composant s'affiche correctement », ce qui n'équivaut pas toujours à « fonctionner correctement », cela donne l'impression de briser l'abstraction et de tester si React fonctionne. Au lieu de cela, que ce soit React, Angular ou Elm, j'ai toujours pensé que tester votre code fonctionnait, en créant principalement des composants purs et en testant les « composants intelligents » (par exemple les composants avec effets secondaires) que vous validez dans les tests d'acceptation (Cypress ou Playwright) .

Les développeurs Web JavaScript ont des opinions variées et des définitions de mots variées. C'est généralement bien, mais en tant que personne qui a eu ThoughtWorks en tant que héros du quartier des jeunes adultes, recommande constamment Martin Fowler et d'autres ouvrages écrits de ThoughtWorks comme de merveilleuses recommandations à apprendre, et j'ai même voulu travailler avec eux un jour… vous pouvez voir pourquoi ce point de vue complètement opposé est me donnant une crise de foi.

Donc :

1. d'accord avec les tests de composants sous diverses formes
2. pas d'accord avec JSDom et « affirme que l'élément 2 de la liste de mes composants a une balise en gras avec le texte intérieur de « vache » » dans la langue de test unitaire de votre choix.

Pour ce que ça vaut, ce qui précède est nuancé dans différentes langues. Angular et Lit/WebComponents, par exemple, si vous évitez que les modèles aient une logique au-delà de if et changez la liaison aux variables de composants publiques, sont beaucoup plus faciles à tester unitairement et à affirmer les effets secondaires par rapport aux frameworks actuels que React et d'autres exposent. Cependant, Angular et certains frameworks WebComponent nécessitent un code de configuration détaillé qui est lui-même extrêmement difficile à déboguer, alors que React/Elm est le contraire.

De plus, je sais que créer ces PDF est un effort herculéen, tout comme essayer de résumer tout ce qui concerne la technologie, donc je suis sûr qu'il me manque juste des litres de contexte.

Déploiement continu : adopter

C'était un boomerang incroyable et voir mon PDG en parler dans son discours annuel. Je sais que la tentative d'événement Minimum CD peut être un énorme changement pour les gens, mais c'est la meilleure façon que j'ai vue de travailler, c'est tellement bon de le voir évidemment évoqué dans Adopt.

Golem : évaluer

J'étais super excité lorsque le créateur de Zio a contribué à la création de cette machine d'État qui ne peut pas planter en tant que service, appelée Golem. J'étais encore plus enthousiasmé car ils prenaient en charge Grain, un langage FP de style OCAML bien typé. Je n’ai tout simplement jamais trouvé le temps ni l’inspiration pour jouer car je me sens toujours piégé dans le vortex « tout est AWS ». Oui, j'ai joué avec et utilisé CloudFlare en production, mais… en tant que fan d'AWS Step Functions, cela semblait être une bonne idée. Un de ces week-ends, j'essaierai à nouveau avec TypeScript car Grain ne semble plus être une option.

Bruno : Adopter

Beaucoup de ces clients REST, certains intégrés à VSCode, sont bloqués par diverses sociétés car ils hébergent les détails de votre API interne sur leurs serveurs ou publient des détails à d'autres endroits. Des choses comme Postman et Insomnia et d’autres ont commencé à nécessiter des abonnements bien qu’ils prétendent que ce n’était pas le cas, ce qui ne fait qu’empirer les choses. Il existe donc une forte pression pour trouver des outils similaires qui ne partagent pas vos données. Bruno est celui que je dois vérifier car je ne suis plus autorisé à utiliser ThunderClient.

Outils de tests de régression visuelle : adopter

Il existe différentes manières pour CSS de casser l'intégralité de votre application, et il n'existe aucun moyen de tester facilement unitairement ou d'accepter un moyen d'empêcher cela. J'ai vraiment eu du mal avec les premiers outils d'instantanés React et j'ai senti que le retour sur investissement n'était pas là pour les petits sites étant donné les nombreux faux positifs. Des outils comme Applit et BackstopJS sont quelques-uns des nombreux services, y compris, permettant de valider l'apparence et le fonctionnement de votre site. Ils s'exécutent souvent après ou en même temps que vos tests d'acceptation dans votre pipeline. J'ai peut-être 5 minutes d'expérience avec les outils Applit, mais je veux absolument découvrir Backstop.

GitButler : évaluer

Celui qui me passionne le plus est GitButler. En tant que personne qui déteste les Pull Requests après avoir expérimenté Trunk Based Dev, et étant déçue par l'état et l'abandon de divers outils autour des « abstractions sur les PR », GitButler semble pouvoir restaurer ma raison dans le contexte du passage à la création de PR de PR.

Mise : évaluer

Mise est un peu bizarre parce que je n'ai jamais eu de problèmes avec nvm pour gérer les versions de Node.js, et pipenv pour gérer/exécuter des projets Python, donc curieux, allez essayer ça et voyez de quoi il s'agit.

Mockoon : évaluer

Je déteste les moqueries. J'ai tendance à travailler dans des langages qui autorisent des effets secondaires et avec des développeurs qui ne suivent pas Pure Core, Imperative Shell. Donc, tout ce que je peux faire pour en savoir plus sur mon ennemi et comment le gérer est une bonne utilisation du temps, et Mockoon est un autre de ces créateurs simulés.

Rspack : évaluer

Heureusement, je n'ai jamais eu à intégrer Webpack. Malheureusement, j'ai été touché à plusieurs reprises par l'intégration d'autres personnes avec Webpack. Vite était une bouffée d'air frais ; super rapide et ça a fonctionné. Il est donc intéressant d’entendre parler d’un autre concurrent en matière de vitesse. Vite a gagné non seulement en raison de sa vitesse incroyable, mais aussi de sa merveilleuse expérience de développement, tellement cool de voir ce qui se passe ici avec Rspack.

Zed : Évaluer

Je suis ravi d'essayer l'IDE Zed même si VSCode s'en prend à moi, notamment parce que la programmation en binôme intégrée, la vitesse ultra rapide et parce que le créateur de Roc Lang a rejoint leur équipe.

Pkl : essai

J'ai été allumé pour la première fois sur Pkl pendant ma phase Dhall Trough of Disillusionment (Dhall est cool, mais mec, c'est dur) par James Ward. Il semblait que ce soit un langage doté de suffisamment de types pour compiler les fichiers de configuration YAML/JSON de manière plus sûre. J'ai eu suffisamment de mauvaises configurations YAML/JSON qui ont interrompu la production, pour que j'ai commencé à chercher des moyens de compiler ces problèmes, et Dhall m'a beaucoup aidé, mais la courbe d'apprentissage et les erreurs du compilateur sont brutales à résoudre, et je n'ai jamais eu d'enthousiasme parmi mes pairs. . En espérant que Pkl fasse des progrès ici.

Conclusion

Assurez-vous de télécharger le PDF vous-même, car j'ai ignoré une TONNE de technologies nouvelles et existantes (LLM, infra, science des données) que je trouve ennuyeuses, mais que d'autres peuvent trouver convaincantes.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!