Gedanken zu ThoughtWorks Radar 4

Der ThoughtWorks 2024 Radar wurde veröffentlicht (Sie können das PDF mit einem Klick herunterladen, keine lästige Anmeldung erforderlich). Unten sind 2 Dinge:

1. ich beschreibe Dinge, über die ich beim Komponententest verwirrt bin
2. Coole neue Tools, um zu untersuchen oder herauszufinden, warum sie von „Bewerten“ zu „Übernehmen“ wechseln

Wenn Sie einfach nur mehr über die coolen neuen Sachen erfahren möchten, die Sie sich ansehen können, überspringen Sie meinen Komponententest-Rant.

Komponententests: Übernehmen

Ich habe viele Fragen zu diesem „Adoptieren“. Mein derzeitiger Arbeitgeber hat viel in Schulungen und Werkzeuge investiert, um Teams bei der Durchführung von Komponententests zu unterstützen, was mir sehr gefällt. Was mir nicht gefällt, ist die weitere Testtechnik, deren Definition je nachdem, wer darüber spricht, unterschiedlich ist.

Lassen Sie mich die wenigen Definitionen, die ich in freier Wildbahn gesehen habe, in der chronologischen Reihenfolge skizzieren, in der ich sie kennengelernt habe, wobei die Definition von ThoughtWorks meiner Meinung nach die letzte ist:

• Storybook zum isolierten Testen von React-Komponenten, häufig genutzt für Komponenten-Framework-Autoren
• Testen von Komponenten in einer isolierten Browserumgebung mit dem Component Testing von Cypress
• Meine neueste Definition von Cypress Whitebox Testing, was bedeutet, dass alle externen I/O-Aufrufe (fetch/xhr, JSON laden, lokalen Speicher lesen usw.) cy.intercepted oder stubbed/mocked sind

Nichts davon ist gleich. Eine Komponente in den oben genannten Kontexten bedeutet sozusagen eine UI-Komponente, entweder so etwas wie a oder a, die viele andere Komponenten, Code und CSS zusammensetzt. Ich sage „irgendwie“, weil Sie in Storybook und Cypress einen echten Browser verwenden, keinen gefälschten wie JSDom. In diesem Zusammenhang glaube ich, dass die Verwendung eines echten Browsers viele Probleme aufdecken kann, insbesondere im Zusammenhang mit Akzeptanztests und nicht mit Unit-Tests. Ich habe die gegenteiligen Erfahrungen zu dem gemacht, was sie zitieren: Sie können Cypress/Playwright extrem schnell machen (nur mit Dingen wie it.only, starkem Stubbing, einer stärker entkoppelten Gestaltung Ihrer Benutzeroberfläche, um bestimmte Benutzerströme zu testen) und der Menge Das Vertrauen, das ich für den Benutzer in die Anwendung habe, ist extrem hoch. Angesichts des Elm-Typisierungssystems ist dies die wichtigste Möglichkeit, das Fehlen von Race-Bedingungen in Ihrem Elm-Code zu überprüfen, und das ist praktisch, da Sie mit dieser Technologie mehr Zeit für das Schreiben von Akzeptanztests aufwenden können. Cypress-Whitebox-Tests sind NICHT flockig; Sie sind deterministisch, deshalb lieben wir sie alle.

Ich bin mir jedoch bewusst, dass das Debuggen eine Herausforderung sein kann. Nur weil Sie sich „in einem Browser“ befinden, erhalten Sie nicht immer umfassende Einblicke in die Gründe dafür, warum etwas kaputt gegangen ist, obwohl Ihnen Haltepunkte, Debugger-Schlüsselwörter, der kompilierte Quellcode, Einblicke in Netzwerkaufrufe und verschiedene Protokolle zur Verfügung stehen (nicht ironisch). , trotz alledem kannst du immer noch sagen „Alter, warum funktioniert das nicht…“)

Als nächstes führen sowohl ThoughtWorks als auch Cypress „End-to-End“-Tests an. Auch hier sind die Definitionen unklar. Hier sind ein paar Definitionen, die ich gesehen habe:

• Dave Farleys e2e-Ansatz, der im Grunde die Zusammenarbeit „aller Dinge“ bestätigt (nicht zu verwechseln mit einem Vorstoß für frühe All-Up-Tests)
• Cypress’ Blackbox-Testing, bei dem Sie KEINE Ajax-Aufrufe und andere I/Os stumm/spotten, sondern nur „Ihre Website und ihre Integrationen“ testen
• ThoughtWorks scheint zu sagen, dass Playwright/Cypress/Selenium in erster Linie E2E-Tools sind, wobei ich sie als Akzeptanztest-Tools betrachte, mit Ausnahme der Cypress Component Testing-Funktionalität, die Storybook ein wenig widerspiegelt
• Hillel Wayne nennt sie auch so

Schließlich habe ich die Komponententesterweiterungen von React noch nie genossen. Sie sind stark von Schein-/Nebeneffekten befallen und fordern Sie dringend dazu auf, JQuery-Kenntnisse zu nutzen, um zu überprüfen, „Meine Komponente wird korrekt gerendert“, was nicht immer gleichbedeutend ist mit „korrekt funktionieren“, sondern sich anfühlen, als würde man die Abstraktion durchbrechen und testen, ob es reagiert funktioniert. Unabhängig davon, ob React, Angular oder Elm, hatte ich immer das Gefühl, dass das Testen Ihres Codes funktioniert, indem in erster Linie reine Komponenten erstellt und die „intelligenten Komponenten“ (z. B. Komponenten mit Nebenwirkungen) getestet werden, die Sie in Akzeptanztests (Cypress oder Playwright) validieren. .

JavaScript-Webentwickler haben unterschiedliche Meinungen und unterschiedliche Definitionen von Wörtern. Das ist im Großen und Ganzen in Ordnung, aber als jemand, der ThoughtWorks als Hood-Held für junge Erwachsene hatte, Martin Fowler und andere von ThoughtWorks verfasste Werke ständig als wunderbare Empfehlungen zum Lernen empfiehlt und eines Tages mit ihnen zusammenarbeiten wollte, können Sie sehen, warum dieser völlig entgegengesetzte Standpunkt ist was mir eine Glaubenskrise beschert.

Also:

1. stimmenKomponententests in verschiedenen Formen zu
2. Ich stimme nicht zu mit JSDom und „Stellen Sie sicher, dass das Listenelement 2 meiner Komponente ein fettes Tag mit dem Innentext ‚Kuh‘ hat“ in der Unit-Test-Sprache Ihrer Wahl.

Was es wert ist, das Obige ist in verschiedenen Sprachen nuanciert. Angular und Lit/WebComponents beispielsweise lassen sich im Vergleich zu den aktuellen Frameworks, die React und andere bereitstellen, viel einfacher Unit-Tests durchführen und Nebenwirkungen feststellen, wenn Sie vermeiden, dass Vorlagen über eine Logik hinausgehen, die über „If“ hinausgeht, und die Bindung auf öffentliche Komponentenvariablen umstellen. Allerdings erfordern Angular und einige WebComponent-Frameworks ausführlichen Setup-Code, der selbst extrem schwer zu debuggen ist, während React/Elm das Gegenteil ist.

Außerdem weiß ich, dass das Erstellen dieser PDFs eine Herkulesaufgabe ist, ebenso wie der Versuch, irgendetwas im technischen Bereich zusammenzufassen. Ich bin mir also sicher, dass mir einfach Unmengen an Kontext fehlen.

Kontinuierliche Bereitstellung: Übernehmen

Es war großartig, Bumerang zu fahren und zu sehen, wie mein CEO in seinem jährlichen Vortrag darüber sprach. Ich weiß, dass der Versuch einer Mindest-CD eine große Veränderung für Menschen sein kann, aber es ist die beste Arbeitsweise, die ich je gesehen habe, und es ist schön zu sehen, dass sie in Adopt offensichtlich zum Ausdruck kommt.

Golem: Bewerten

Ich war total begeistert, als der Zio-Erfinder an der Entwicklung dieser Zustandsmaschine, die nicht zum Absturz kommen kann, als Dienst namens Golem beteiligt war. Ich war noch aufgeregter, weil sie Grain unterstützten, eine solide typisierte FP-Sprache im OCAML-Stil. Ich konnte einfach nie die Zeit/Inspiration zum Spielen finden, da ich mich immer noch im Strudel „Alle Dinge sind AWS“ gefangen fühle. Ja, ich habe mit CloudFlare herumgespielt und es in der Produktion verwendet, aber … als AWS Step Functions-Fan schien mir das eine coole Idee zu sein. Eines dieser Wochenenden werde ich es noch einmal mit TypeScript versuchen, da Grain anscheinend keine Option mehr ist.

Bruno: Adoptieren

Viele dieser REST-Clients, von denen einige in VSCode integriert sind, werden von verschiedenen Unternehmen blockiert, weil sie Ihre internen API-Details auf ihren Servern hosten oder Details an anderen Orten veröffentlichen. Dinge wie Postman und Insomnia und andere verlangen inzwischen Abonnements, obwohl sie behaupten, dass dies nicht der Fall sei, was die Sache nur noch schlimmer macht. Es besteht daher ein großer Druck, ähnliche Tools zu finden, die Ihre Daten nicht weitergeben. Bruno ist einer, den ich mir ansehen muss, da ich ThunderClient nicht mehr verwenden darf.

Tools für visuelle Regressionstests: Übernehmen

Es gibt verschiedene Möglichkeiten, wie CSS Ihre gesamte Anwendung beschädigen kann, und es gibt keine Möglichkeit, dies einfach durch Unit-Tests oder Akzeptanztests zu verhindern. Ich hatte wirklich Probleme mit den frühen React-Snapshot-Tools und hatte das Gefühl, dass der ROI für kleinere Websites angesichts der zahlreichen Fehlalarme nicht ausreichte. Tools wie Applit und BackstopJS sind einige der vielen Tools, einschließlich Diensten, mit denen Sie überprüfen können, ob Ihre Website ordnungsgemäß aussieht und funktioniert. Sie werden häufig nach oder gleichzeitig mit Ihren Abnahmetests in Ihrer Pipeline ausgeführt. Ich habe vielleicht 5 Minuten Erfahrung mit Applit-Tools, möchte aber auf jeden Fall Backstop ausprobieren.

GitButler: Bewerten

Am meisten freue ich mich auf GitButler. Als jemand, der Pull Requests hasst, nachdem er Trunk Based Dev kennengelernt hat und vom Zustand und Verzicht auf verschiedene Tools rund um „Abstraktionen statt PRs“ enttäuscht ist, sieht es so aus, als könnte GitButler meinen Verstand wiederherstellen, wenn ich dazu übergehe, aus PRs PRs zu machen.

Mise: Bewerten

Mise ist irgendwie seltsam, weil ich noch nie Probleme mit nvm für die Verwaltung von Node.js-Versionen und mit Pipenv für die Verwaltung/Ausführung von Python-Projekten hatte, also probieren Sie es neugierig aus und sehen Sie, worum es bei der ganzen Aufregung geht.

Mockoon: Bewerten

Ich hasse Spott. Ich neige dazu, in Sprachen zu arbeiten, die Nebenwirkungen zulassen, und mit Entwicklern, die Pure Core und Imperative Shell nicht folgen. Alles, was ich tun kann, um mehr über meinen Feind zu erfahren und wie ich mit ihm umgehe, ist also eine gute Zeitnutzung, und Mockoon ist einer dieser Scheinersteller.

Rspack: Bewerten

Zum Glück musste ich nie eine Integration mit Webpack durchführen. Leider war ich mehrfach von der Integration anderer Leute mit Webpack betroffen. Vite war ein Hauch frischer Luft; Super schnell und es hat funktioniert. Daher ist es interessant, von einem weiteren Konkurrenten in Sachen Geschwindigkeit zu hören. Vite hat nicht nur wegen seiner erstaunlichen Geschwindigkeit gewonnen, sondern auch wegen seiner wunderbaren Entwicklererfahrung. Sehen Sie sich also an, was hier mit Rspack passiert.

Zed: Bewerten

Ich freue mich darauf, die Zed-IDE auszuprobieren, obwohl VSCode mich im Griff hat, vor allem wegen der integrierten Paarprogrammierung, der superschnellen Geschwindigkeit und weil der Roc-Lang-Entwickler seinem Team beigetreten ist.

Pkl: ​​Prozess

Ich wurde zum ersten Mal während meiner Dhall Trough of Desillusionment-Phase (Dhall ist cool, aber Mann, ist das schwer) von James Ward auf Pkl aufmerksam. Es schien eine Sprache zu sein, die über genügend Typen verfügte, um YAML/JSON-Konfigurationsdateien viel sicherer zu kompilieren. Ich hatte genug YAML/JSON-Fehlkonfigurationen, die die Produktion unterbrachen, sodass ich begann, nach Möglichkeiten zu suchen, diese Probleme durch Kompilierung zu beseitigen, und Dhall hat mir sehr geholfen, aber die Lernkurve und die Compilerfehler sind brutal zu bewältigen, und ich habe unter meinen Kollegen nie Aufsehen erregt . Ich hoffe, dass Pkl hier Erfolg hat.

Abschluss

Laden Sie das PDF unbedingt selbst herunter, da ich dort eine Menge neuer und bestehender Technologien (LLMs, Infrastruktur, Datenwissenschaft) ignoriert habe, die ich langweilig finde, andere aber vielleicht überzeugend finden.

Das obige ist der detaillierte Inhalt vonGedanken zu ThoughtWorks Radar 4. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!