Hallo allerseits, mein Name ist Jaroslaw Astafjew, und heute möchte ich eine Führung zum Testen von ReactJS durchführen. Ich werde mich nicht mit der Komplexität des Testens von Webanwendungen unter Verwendung bestimmter Bibliotheken befassen (geleitet von dem Ansatz „Es ist schwierig, nur schlechten Code zu testen“). Im Gegenzug werde ich versuchen, Ihren Horizont zu diversifizieren. In diesem Artikel ist React eher eine Gelegenheit, Testansätze zusammenzustellen, ein Ausgangspunkt, der Hipster und Technologie kombiniert. Es wäre richtiger zu sagen, dass wir über die Prinzipien des Testens im Allgemeinen mit Abbildungen zu ReactJS (und nicht nur) sprechen werden.
Wenn Sie sich als Testguru betrachten -
überspringen Sie die erste Hälfte des Artikels , es geht um die Grundprinzipien des Testens. Wenn der zweite Teil nichts Neues für Sie enthüllt, kommen Sie zu uns, um zu arbeiten und zu lehren, wie es geht.
Wenn die Einführung keinen Synästhesieanfall verursachte, willkommen bei cat.
Unit-Tests
Unit Jest ist eine Bibliothek zum Testen von JavaScript. Mag das nicht - nimm einen
anderen , aber dann ist
Ava besser. Hier ist alles einfach: Klicken Sie auf den magischen Knopf und stellen Sie sicher, dass ein bestimmter Wert von "0" in "1" geändert wurde:
import React from "react" import { MyButton } from "../src/components/dummy/myButton" import renderer from "react-test-renderer" test("MyButton has onPress fn", () => { let x = 0 const instance = renderer .create(<MyButton onPress={() => x++} />) .getInstance() expect(instance.handlePress).toBeDefined() expect(x).toBe(0) instance.props.handlePress() expect(x).toBe(1) })
Jetzt haben Sie alle notwendigen Fähigkeiten , um den magischen Knopf zu testen. Leider hängen diese Fähigkeiten nicht mit dem wirklichen Leben zusammen. Die React-Komponente kann nicht so gut isoliert werden, und die Isolierung ist eines der Hauptprinzipien der Einheitentests. Irgendwie ist es notwendig, alle Komponenten zu entfernen, die irgendwie an der Rendermethode teilnehmen, mit Ausnahme der getesteten. Und es gibt eine Lösung: Kluge Leute haben sich dafür mockAPI ausgedacht.
Die Essenz von Mock ist einfach: Alles, was uns nicht gehört, ist
Mock / Stub / Fake / Dummy / Spy usw. Wir "emulieren" die Art und Weise, wie wir das tatsächliche Verhalten einer Komponente, die eine komplexe Logik aufweisen kann, anhand vorbereiteter Testdaten benötigen, und gehen davon aus, dass alle emulierten Komponenten einwandfrei funktionieren, wenn die richtigen Parameter eingegeben werden.
Es gibt eine
Jest-Fetch-Mock- Bibliothek für
Jest , in der Sie Moki global definieren können. Wenn Ihnen diese Option nicht gefällt, können Sie jede Komponente, die Sie im Test benötigen, separat „benetzen“.
Eine reine Funktion am selben Eingang gibt immer die gleiche Antwort zurück. Wenn die Komponenten in unserer Geschäftslogik "nicht saubere" Funktionen / Komponenten haben, müssen sie in Unit-Tests ebenfalls "gelöscht" werden (für Unit-Tests gilt diese Regel jedoch nicht immer). Ein klassisches Beispiel ist eine Reaktionskomponente, die das aktuelle Datum und die aktuelle Uhrzeit in dem von Ihnen benötigten Format anzeigt. Das Datum ist jedes Mal anders, wenn Sie die Tests ausführen, und Sie können nicht die richtigen Komponententests schreiben. Für alle, die nicht einverstanden sind, können Sie das Beispiel komplizieren, in dem Ihre Komponente das Datum im relativen Format anzeigen und Datumsangaben, die älter als ein
Jahr ab dem aktuellen Datum sind, rot hervorheben soll.
Wenn Sie also dynamische Dinge haben, die von Zeit / Wetter / Druck abhängen, definiert Mock den Anruf, den Sie benötigen, neu, sodass keine Abhängigkeit von Faktoren Dritter besteht. Sie müssen also nicht
am 29. Februar warten, um einen gefallenen Test zu erwischen.
Unit Test Regeln
Die oben beschriebenen Probleme und Methoden zu ihrer Lösung sind Versuche eines informellen Testansatzes: Jeder Test läuft wie gewünscht. Meiner Meinung nach ist die Einhaltung von
drei wichtigen Regeln für Unit-Tests ausreichend:
- Determinismus
- Isolierung
- Unabhängigkeit von externen Faktoren
- Gesunder Menschenverstand
Regel eins: Alle Tests müssen deterministisch sein. Wenn ich einen Test unter Windows geschrieben habe, sollte er auf einem Mac ebenfalls gestartet werden und das gleiche Ergebnis liefern. Windows-Entwickler vergessen gerne, dass bei Dateinamen auf * nix-Systemen zwischen Groß- und Kleinschreibung unterschieden wird. Und Sie haben Glück, wenn die
Tests in den Rahmen von CI fallen und nicht in die Anwendung in der Produktion .
Die nächste Regel ist die Isolation. Wir benetzen alle nicht getesteten Komponenten. Wenn dies schwierig ist, ist es Zeit für eine Umgestaltung.
Last but not least: Wenn Ihre Anwendung zur Laufzeit Daten erhält, müssen diese ebenfalls festgenagelt werden. Dies kann ein Gebietsschema, eine Fenstergröße, ein Datumsformat, ein Gleitkommazahlenformat usw. sein.
Integrationstests
Wann mit dem Schreiben von Integrationstests begonnen werden soll, ist meiner Meinung nach eine offene Frage, und in jedem einzelnen Team / Produkt sollte die Entscheidung unter Berücksichtigung interner Faktoren getroffen werden.
Sie können einen formalen Ansatz wählen: Erreichen Sie eine Abdeckung von
80% für Unit-Tests (schlecht geschriebene Tests sollten nicht überprüft werden / erfordern nur neuen oder geänderten Code, der durch Tests abgedeckt wird), führen Sie dann eine vollständige Prüfung und Umgestaltung aller schriftlichen Tests mit Analyse typischer Fehler durch, formalisieren Sie interne Regeln für das Schreiben von Tests und Führen Sie solche Razzien pro Jahr durch. Wenn nach all den oben beschriebenen Aktionen die Codeabdeckung Ihrer Komponententests immer noch 80% + beträgt, haben Sie ein ausgereiftes Team oder stehen Ihrem Code / Ihren Tests einfach nicht kritisch gegenüber. Wenn die Codeabdeckung geringer geworden ist, müssen Sie erneut eine Abdeckung von 80% erreichen und mit dem Schreiben von Integrationstests fortfahren. Sie können weniger formal auftreten und sich einfach vom gesunden Menschenverstand leiten lassen: Schreiben Sie beispielsweise für jeden Fehler, der n-mal gespielt wurde, einen Test oder lassen Sie sich etwas anderes einfallen, z. B. werfen Sie eine Münze.
Die zweite offene Frage:
Welche Tests gelten als Integration ? Vielleicht unbeantwortet lassen.
In Integrationstests testen wir die Arbeit nicht einer Komponente, sondern mehrerer Komponenten in einem Bündel. Es gibt keine Regeln, aber der gesunde Menschenverstand sagt Ihnen:
- Testen Sie nicht, wie es gerendert wird, wo es aufgerufen wird und wann alles enden wird.
- Testen Sie die Arbeit von ReactJS nicht. Wenn sie nicht funktioniert, hilft Ihnen nichts.
- Testen Sie nicht, wie die Zustandsmaschine React funktioniert.
- Testen Sie die Geschäftslogik / das Datenmodell / die Grenzsituationen / etwas, das häufig kaputt geht.
Bei solchen Tests sollten Sie nicht auf Details eingehen. Sie laufen merklich länger und es ist auch schwieriger, sie zu schreiben. Sie sollten sich also nicht mitreißen lassen und jeden kleinen Fall in der Logik der Anwendung behandeln. Dies ist teuer in Bezug auf die Vermietung der Infrastruktur und lang in Bezug auf Entwicklung und Skriptausführungszeit. Jemand wird sein Leben mit dieser Routine verbringen, und der
Benutzermanager wird traurig sein und auf neue Funktionen warten und ...
Ein weiterer Grund, warum Sie nicht versuchen sollten, alles zu testen, ist False Security (ich habe versucht, die wichtigsten Punkte oben zu schreiben). Jedes Team sollte über Fehler der ersten und zweiten Art, das Neumann-Pearson-Lemma, lesen und ihre Risiken in Bezug auf Geld, Papageien oder andere im Team akzeptierte Wahrheitsmaßstäbe bewerten.
Es gibt jedoch Ausnahmen von dieser und jeder anderen Regel.
Vergessen Sie alles, was oben gesagt wurde :
- Beim Testen dynamischer Abhängigkeiten. Wenn Sie nicht wissen, welche Komponente zur Laufzeit verfügbar sein wird, rendern Sie sie, aber möglicherweise nicht. Sie müssen auch einen Test dafür schreiben, niemand hat den Circuit Bracker abgebrochen. Entweder die falsche Komponente, die Sie erwartet haben, oder eine defekte Komponente wird kommen. Daher schreiben wir in diesem Fall einen Integrationstest und rendern. Wir prüfen, ob alles funktioniert, wenn nichts fällt.
- Mit pixel perfect (na ja, Sie verstehen) muss die Entwicklung Screenshots rendern und diffundieren. Jedes Mal, wenn die Komponentenbibliothek auf eine neue Version aktualisiert wird, aktualisieren Sie die Referenz-Screenshots. Weil es einfacher ist
, einen neuen Designer für die Abstimmung zu engagieren als zu reparieren.
Schnappschuss-Tests
Der einfachste Integrationstest ist eine Momentaufnahme:
- Wir nehmen eine Komponente, rendern sie
- Im Render schreiben wir console.log (this)
- Kopieren Sie die Referenzdaten von der Konsole
- Vergleichen
Wenn Sie ein wenig verwirrt sein möchten, empfehle ich Ihnen, mit der
StoryBook- Bibliothek
herumzuspielen . Dies ist eine Bibliothek für Snapshot-Tests, die im Übrigen die Idee von
StyleGuidist zusammenfasste - das Erstellen eines eigenen
Designsystems basierend auf React-Komponenten.
Die erste Regel des Snapshot-Tests:
Sagen Sie niemals , versuchen Sie, die Daten zu testen . Sie sollten immer statisch, „eingesperrt“ und unabhängig sein. Die zweite Regel: Ein
fehlerhafter Schnappschuss-Test bedeutet nicht, dass alles schlecht ist . Wenn er rot ist - nicht die Tatsache, dass alles gelaufen ist. Es gibt viele Optionen, um das Layout gleich zu machen, aber der DOM-Baum war anders. Daher ignorieren wir Leerzeichen, Attribute, Schlüssel oder testen nicht, was so viel Supportzeit erfordert. Oder wir markieren mit unseren Händen, was kaputt ist, was nicht. Wir beheben die fehlerhaften Tests und starten das StoryBook im Scheinaktualisierungsmodus neu - dem Modus, in dem der Test Komponenten rendert und Snapshot als Referenzwert in den erwarteten Zustand einfügt.
xState and React Automata
ReactJS ist eine schwierige Sache. Es scheint, dass die Bibliothek cool ist. Ich habe drei Komponenten erstellt - eine Klasse: und die Zustandsmaschine scheint zu funktionieren und der Code ist wunderschön. Dann schreibst du sechs Monate lang auf ReactJS, siehst dir den Code an - eine Art Unsinn. Du verstehst nicht, wo die Krücken sind, wo die Routen, wo der Staat, wo die Caches ... Dann denkst du: Nun, ich werde tun, was Facebook rät: Ich werde die "Hokeys", "Haken", etwas anderes befestigen und dich plötzlich dabei erwischen, wie du Wolle hh. ru in versucht, ein projekt mit entwicklung auf die reaktion von grund auf neu zu finden, so dass es sicher
alles schön machen wird ...
Alles ist so kompliziert, dass es im Allgemeinen unmöglich ist zu verstehen, wie es funktioniert. Und es funktioniert, bis sich jemand beschwert. Wir reparieren es - und es repariert, bricht aber herum ... Eine der Ausgaben ist eine Zustandsmaschine, eine Reihe deterministischer Anwendungszustände und zulässige Übergänge zwischen ihnen. Und wie sie in engen Kreisen sagen, haben Sie nicht über die Reaktion geschrieben, wenn Sie Ihre Zustandsmaschine nicht verletzt haben.
Es lohnt sich,
xState zurückzurufen . Dies ist eine deterministische Zustandsmaschine für JavaScript.
Sie können auf
xState eine sehr coole Benutzeroberfläche
erstellen - einen Link zum entsprechenden Bericht finden Sie in der Dokumentation der
React Automata- Bibliothek. React Automata ist wiederum die Bibliothek, in der xState in ReactJS angepasst wurde. Darüber hinaus kann sie
Tests für den Zustand einer Zustandsmaschine generieren .
Wenn das erste Häkchen wahr ist, leuchtet das grüne Licht. Wenn der zweite falsch ist, wird ein grauer Hund gezeichnet, und React Automata generiert Tests für alle vier Kombinationen dieser Parameter und validiert den Hund und die Zwiebeln. Irgendwann werden Sie zwar die Hälfte der Tests reduzieren wollen, aber zunächst werden Sie sehr glücklich sein ... Auf jeden Fall ist dies ein bequemer Blick auf Ihre Tests von der Seite, der mich sehr an die Idee erinnert, mit deterministischem Chaos zu testen.
Zypresse
Mit Schnappschuss haben wir mehr oder weniger herausgefunden, dass Sie in Richtung end2end gehen können. Wir haben alle Produkte intern, daher sind lokale Lösungen unsere einzige Option. Ich hoffe, dass Sie die Möglichkeit haben, Cloud-Lösungen zu verwenden, dann wird sich so etwas wie
Cypress als nützlich erweisen.
Zuvor haben Sie Test-Frameworks ausgewählt, Bibliotheken zur Bestätigung und Bibliotheken zum Vergleichen komplexer XMLs verwendet. Dann haben wir einen Treiber und einen Browser ausgewählt, um alles zu starten. Sie fingen an und schrieben eine Reihe von Tests. All dies verschlingt die Infrastruktur, Sie müssen alles in den Docker stopfen und dann etwas anschrauben, das die Tests in der Dynamik betrachtet, analysiert, zeigt, was falsch ist ...
Die Cypress-Leute haben alles für dich getan. Sie lösten verschiedene Probleme:
Einrichten einer Arbeitsumgebung, Schreiben von Code, Ausführen und Schreiben von Tests. Wenn der Test fehlerhaft ist, können Sie einen Screenshot anzeigen, in dem hervorgehoben wird, was fehlerhaft ist. Es funktioniert zwar nicht für Mobiltelefone, aber es gibt zum Beispiel
Detox . Dies ist natürlich unter dem Gesichtspunkt der Eingabeschwelle schwierig: Sie müssen Ihre Anwendung darauf abstimmen, eine Reihe von Dateien neu schreiben usw. Aber wenn Sie möchten, ist es möglich.
Weiche Tests
Es gibt alternative Arten von Tests, die auch nicht als gute Tests bezeichnet werden können. Ich nenne sie weiche Tests. Zum Beispiel Linter. Sie werden hauptsächlich vom Front-End verwendet (und manchmal kommt die Inspiration sogar von Javisten). Es gibt viele Linters:
ESLint ,
JSHint ,
Prettier ,
Standard ,
Clinton . Ich rate
Prettier: schnell, billig, fröhlich, einfach zu konfigurieren, funktioniert sofort .
Wenn Sie verwirrt sein möchten, können Sie ESLint konfigurieren. Lassen Sie mich Ihnen ein klassisches Beispiel für ein Plugin geben: Wenn ein Kunde Kommentare mit obszönen Ausdrücken in Ihrem Code findet, schwört er normalerweise. Tricky Entwickler machen Kommentare auf Russisch, damit der Kunde nicht errät. Aber der Kunde vermutete ... benutzte einen Google-Übersetzer und fand alles heraus, was die Entwickler über ihn denken. Der Ausweg aus der Situation ist unangenehm, möglicherweise mit dem Verlust von Geld oder Kunden. In diesen Fällen können
Sie jederzeit ein Plugin für ESLint entwickeln , das die "russischen Muttersprachler" in Ihrem Quellcode findet und sagt: "Oh, sorry, lehnen Sie Ihr Commit ab."
Das Schöne an Lintern in JavaScript ist, dass sie
auf einen Pre-Commit-Hook gesetzt werden können . Persönlich mag ich es nicht, dass Prettier keine Geschichte speichert (obwohl es andererseits auch keine technischen Schulden ansammelt). Unter dem Gesichtspunkt der statistischen Analyse des Codes sind solche Tests miserabel, da Sie die Dynamik des Projekts nicht sehen können und sehen können, wie viele Fehler gestern, vorgestern, aufgetreten sind. Im Prinzip wird dieses Problem in
SonarQube gelöst, es ist auch in der Cloud-Lösung. Dies ist ein statistischer Code-Analysator, der den Verlauf von Läufen speichert und mit zwei Dutzend Sprachen arbeiten kann, einschließlich sogar PHP (wer braucht sonst nicht die eiserne Hand der statischen Analyse? :)). Darin können Sie die Dynamik Ihrer Schwachstellen, Fehler, technischen Schulden und mehr beobachten.
Komplexitätstests
Frontender verwenden
Linters, weil sie schöne Einkerbungen wollen . Komplexität ist auch ein Softtest, mit dem Sie versuchen können, die Qualität Ihres Codes zu überprüfen.
Das Bild zeigt, wie ich versuche, dem Gedanken des Junior zu folgen, der die Pull-Anfrage gestellt hat. In solchen Fällen schlage ich vor, alles abzureißen und eine direkte Straße zu bauen.Komplexitätstests folgen einem sehr einfachen Prinzip: Sie berechnen die
zyklomatische Komplexität des Algorithmus. Zum Beispiel lesen sie eine Funktion und finden darin 10 Variablen. Wenn 10 - wahrscheinlich ist es schwierig. Setzen wir die Komplexität 1. Für jeden Zyklus geben wir 3 Punkte, für einen Zyklus in einem Zyklus - 9, für jeden Zyklus in einem Zyklus eines Zyklus - 27. Wir addieren alles und sagen: Die zyklomatische Komplexität beträgt 120, und eine Person kann nur 6 verstehen. Die Bedeutung dieser Bewertung ist um subjektiv zu sagen, wann Sie Ihren Quellcode umgestalten, in Teile zerlegen, neue Funktionen hervorheben und dergleichen müssen. Und ja, SonarQube kann das auch.
Alternative Tests
In meiner Welt gelten alternative Tests auch für Softtests.
Solidarität ist eine sehr nützliche Sache für das Onboarding. Und das nicht nur für das Frontend, obwohl es in JavaScript geschrieben ist. Damit können Sie
die Arbeitsumgebung testen . Zuvor war es notwendig, umfangreiche Anweisungen zu verfassen, in denen die Versionen der Programmiersprache, die Bibliotheken, die Liste der erforderlichen Software angegeben waren, um einfach zu starten, alles auf dem neuesten Stand zu halten usw. Jetzt können wir Folgendes sagen: „Hier ist Ihr Computer, hier ist der Quellcode. Komm nicht, bis die
Solidarität vorbei ist. “ Gleichzeitig ist die Eintrittsschwelle niedrig. Solidarität kann Fingerabdrücke einer angepassten Arbeitsumgebung erstellen und ermöglicht es Ihnen, sehr einfache Regeln hinzuzufügen, um nicht nur installierte Software zu validieren. Und es macht dich wütend, wenn sie die Worte finden: "Oh, tut mir leid, da funktioniert etwas für mich nicht, kannst du helfen? ..."
Der zweite Anwendungsfall (es ist der Hauptanwendungsfall) ist das
Testen der Produktionsumgebung mit den Worten: „Unit-Tests für CI wurden zwar bestanden, aber die Konfigurationen von CI und PROD variieren erheblich. Es gibt also keine Garantien ... ". Das Ziel der Bibliothek ist sehr einfach: die erste Regel der kontinuierlichen Integration zu erfüllen: "Jeder sollte die gleiche Umgebung haben." Sauber, isoliert, damit es keine Nebenwirkungen gibt, oder zumindest, damit es weniger gibt ... wen versuche ich zu täuschen?
API-Aufruf
Es kommt vor, dass Entwickler in mehrere Teams aufgeteilt sind - einige schreiben ein Frontend, andere schreiben ein Backend. Eine fiktive Situation, die nicht in einem echten Team sein kann: Alles hat gestern funktioniert, und heute nach zwei Veröffentlichungen - vorne und hinten - ist alles kaputt gegangen. Wer ist schuld? Ich als Person mit anfänglicher Backend-Erfahrung sage immer: Frontend.
Es ist einfach, sie haben wie immer irgendwo etwas durcheinander gebracht. Irgendwann kommen die Front-End-Anbieter und sagen: „Hier haben wir den Beitrag als
Referenz gelesen, den Leitfaden durchgesehen und
gelernt, wie Sie Ihre REST-API umwandeln . Und du wirst nicht glauben, dass es sich geändert hat ... " Wenn Ihre Backends nicht mit Swagger, openAPI oder ähnlichen Lösungen befreundet sind, sollten Sie sich im Allgemeinen eine Notiz machen.
Leistung js
Und schließlich der Performance-JS-Test.
Niemand außer Browser-Herstellern
testet die Leistung von JS . In der Regel verwenden alle
Benchmark.js . "Oh, und wir haben unseren Explorer 18 Jahre lang getestet, damit er ein Milliarden-pro-Milliarde-Tablet schneller anzeigt als in Chrome." Wer braucht schon so ein Tablet?
Wenn Sie Leistungstests durchführen möchten, ist es besser, den anderen Weg zu gehen: End-to-End testen und beobachten, wie es funktioniert. Der Benutzer macht sich ein Bild davon, wie die Anwendung als Ganzes funktioniert. Dem
Benutzer ist es egal, dass dies Probleme auf der Backend-Seite sind.Kriegsgeschichte # 1
Nun ein Beispiel aus dem Leben. Irgendwie kommen die Chefs zu uns und sagen: „Ihre Front funktioniert sehr schlecht, sie wird kaum geladen. Mit der Aufführung muss etwas getan werden, die Leute beschweren sich. “ Wir denken: Jetzt haben wir zwei Wochen Zeit, um das Tuning durchzuführen, Protokolle auszuwählen,
warum Sie aktualisiert haben , Baumschütteln auszuwählen, alles mit dynamischer Belastung in Stücke zu schneiden ... Was ist, wenn es nicht ausbrennt, werden wir alles auflösen oder es nur noch schlimmer machen? Es muss eine alternative Lösung gefunden werden.
Wir öffnen den Browser, schauen: 7,5 MB, 2 Sekunden, alles ist in Ordnung.
Setzen Sie Nginx GZip:
Nginx kann das Komprimierungsverhältnis anpassen. Versuchen wir Folgendes:
Wachstum - 25% der Produktivität. Hör früh auf. Schauen Sie sich das kleine Designer-Logo in der Ecke an. Es bleibt sehr schön, auch wenn es gedehnt ist, aber warum brauchen wir es?
Folgendes haben Sie erhalten, nachdem Sie ein Bild optimiert haben. Sie können das Gewicht des Logos selbst bewerten. Schließlich kommen wir zum Kunden und sagen: „Der erste Download ist nicht so wichtig wie der zweite. Aktivieren Sie das erzwungene Caching:
... Jeder ist glücklich, jeder ist fröhlich! " Mit Ausnahme des Benutzers natürlich.
Aus diesem Grund haben wir beschlossen, häufiger ein Größenaudit durchzuführen.
Gzip, Schriftarten, Bilder, Stile - Orte, an denen selten jemand hinschaut, aber es gibt viele Vorteile.
Madge und updtrJS
Nächster Schritt:
Abhängigkeitsprüfung .
Madge ist so etwas, das den Code analysiert und sagt: Hier ist eine Klasse, die so und so mit so und so verbunden ist, usw. Wenn alles durch eine Komponente geht und es bricht, wird es wenig angenehm sein. Madge ist ein großartiges Visualisierungswerkzeug, das jedoch nur für die manuelle Erkundung geeignet ist. Es gibt eine solche zirkuläre Option, die nach allen
zyklischen Abhängigkeiten in Ihrem Projekt sucht. Wenn es welche gibt, ist es schlecht, wenn nicht, dann haben sie noch nicht geschrieben.
Der Schmerz
älterer Frameworks und Bibliotheken wird mit
updtrJS fast behoben.
Haben Sie 70.000 Codezeilen? Versuchen Sie, von der 13. Reaktion zur 16. zu wechseln?
Updtr hilft Ihnen nicht beim Verschieben, aber es hilft Ihnen zu erkennen, in welche Versionen von Bibliotheken Sie ohne
schwerwiegende Konsequenzen verschieben können . Darüber hinaus können Entwickler im Trend bleiben und die Abhängigkeiten auf dem neuesten Stand halten. Wenn Sie eine gute Testabdeckung haben, empfehle ich.
Statische Typen
Verwenden Sie die statische JS-Typisierung , da die dynamische
JS- Typisierung überhaupt keine Funktion ist, sondern ein Abgrund. Flow, TypeScript, ReasonML das ist alles ...
Chaostests
Das Wesentliche beim Testen von Chaos ist einfach: Starten Sie den Browser und stöbern Sie alles, was gestochert wird, geben Sie alles ein, was in alle Felder eingegeben wurde, und so weiter. Bis es kaputt geht. Amazon, exceptions . , « , ». , . :
Gremlin.com Chaos Monkey .
React — 16- , componentDidCatch. , exception, . .
Naughty String , , . , « », internal server error, ?
War Story #2
– . . def generateRandomPostfix(String prefix) { return prefix + "-" + Math.abs(new Random().nextInt()).toString() } def "testCorrectRandomPostfix"(){ given: def prefix = "ASD" when: def result = generateRandomPostfix(prefix) then: result?.matches(/[a-zA-Z]++-[0-9]++/) }
. . , .
. ASD, , . . ( , groovy). Java integer 1 integer. integer integer — .
, . . ? «+» fromX. , - , XML .
.
.
TestCheck.JS — . , , . —
Flow-To-Gen : Flow , .
check( property( gen.int, gen.int, (a, b) => a + b >= a && a + b >= b ) )
{ result: false, failingSize: 2, numTests: 3, fail: [ 2, -1 ], shrunk: { totalNodesVisited: 2, depth: 1, result: false, smallest: [ 0, -1 ] } }
TestCheck « », . , . , , : 0 -1. 2 -1, , . Sehr cool!
. . , . , ? -? permission'? ? , , , , .
3rd party failures . „ “ — .
Production-
production 16- React :
ErrorCeption HoneyBadger (
Sentry ). ,
.Optimizely /-. , , , , , .
Out of the box
JS — . , JavaScript. —
validator.w3.org/checklink . , , , , .
, , .
Achecker.ca/checker .
Webpagetest.org — , .
Tools.pingdom.com — .
www.w3.org/WAI/ER/tools .
. . , Jenkins Multibranch Plugin, - -. -, (« , »), nightly-, - regress, full regress, smart regress ..
— , , , , . , , , .
, , . .