Maximieren Sie Ihre Front-End-Test-Locators

Automatisierte Front-End-Tests sind fantastisch. Wir können einen Test mit Code schreiben, um eine Seite zu besuchen - oder nur eine einzelne Komponente zu laden - und den Testcode auf Dinge klicken oder Text wie ein Benutzer eingeben, und dann Behauptungen über den Status der Anwendung nach den Interaktionen vorlegen. Auf diese Weise können wir bestätigen, dass alles, was in den Tests beschrieben wird, wie in der Anwendung erwartet funktioniert.

Da es sich bei diesem Beitrag um einen der Bausteine ​​von automatisierten UI -Tests handelt, gehe ich nicht zu viel Vorwissen aus. Überspringen Sie die ersten Abschnitte, wenn Sie bereits mit den Grundlagen vertraut sind.

Struktur eines Front-End-Tests

Es gibt ein klassisches Muster, das beim Schreiben von Tests nützlich ist: arrangieren , handeln , behaupten . In Front-End-Tests führt dies zu einer Testdatei, die Folgendes ausführt:

1. Arrangieren: Machen Sie sich die Dinge für den Test vor. Besuchen Sie eine bestimmte Seite oder montieren Sie eine bestimmte Komponente mit den richtigen Requisiten, verspotten Sie einen Zustand, was auch immer.
2. Handlung: Mach etwas mit der Anwendung. Klicken Sie auf eine Schaltfläche, füllen Sie ein Formular aus usw. oder nicht, für einfache Status-Checks können wir dies überspringen.
3. Assert: Überprüfen Sie ein paar Sachen. Hat das Einreichen eines Formulars eine Dankesnachricht angezeigt? Hat es mit einem Beitrag die richtigen Daten an das Back End gesendet?

Wenn Sie angeben , mit der Sie interagieren und später auf der Seite überprüfen sollten , können wir verschiedene Element -Locators verwenden, um die Teile des DOM zu zielen, die wir verwenden müssen.

Ein Locator kann so etwas wie die ID eines Elements, der Textinhalt eines Elements oder ein CSS-Selektor sein, wie .blog-post oder sogar Artikel> Div.Container> Div> p: n-Kind (12). Alles an einem Element, das dieses Element in Ihrem Testläufer identifizieren kann, kann ein Locator sein. Wie Sie wahrscheinlich bereits von diesem letzten CSS -Selektor erzählen können, gibt es in vielen Sorten.

Wir bewerten die Locators oft in Bezug auf spröde oder stabile. Im Allgemeinen möchten wir die stabilsten Elementlokatoren, damit unser Test immer das Element finden kann, das er benötigt, auch wenn sich der Code um das Element im Laufe der Zeit ändert. Die Maximierung der Stabilität um alle Kosten kann jedoch zu Defensiv-Testschreiber führen, die die Tests tatsächlich schwächt. Wir erhalten den größten Wert, indem wir eine Kombination aus Sprödigkeit und Stabilität haben, die mit dem übereinstimmt, was unsere Tests interessieren.

Auf diese Weise sind Elementlokatoren wie Klebeband. Sie sollten in einer Richtung wirklich stark sein und leicht in die andere Richtung reißen. Unsere Tests sollten zusammenhalten und weiterhin bestehen, wenn unwichtige Änderungen an der Anwendung vorgenommen werden. Sie sollten jedoch leicht scheitern, wenn wichtige Änderungen vorkommen, die dem widersprechen, was wir im Test angegeben haben.

Anfängerleitfaden zu Element-Locators in Front-End-Tests

Stellen wir zunächst so, dass wir Anweisungen für eine tatsächliche Person schreiben, um ihren Job zu erledigen. Ein neuer Gate -Inspektor wurde gerade bei Gate Inspectors, Inc. eingestellt. Sie sind ihr Chef, und nachdem alle vorgestellt wurden, sollten Sie ihnen Anweisungen zur Prüfung ihres ersten Tores geben. Wenn Sie möchten, dass sie erfolgreich sind, würden Sie ihnen wahrscheinlich keine solche Notiz schreiben:

Gehen Sie an dem gelben Haus vorbei und machen Sie weiter, bis Sie auf das Feld getroffen haben, auf dem Mike's Mutter die Ziege der Mutter in dieser Zeit vermisst, dann biegen Sie links ab und sagen Sie mir, ob das Tor vor dem Haus auf der anderen Straßenseite von Ihnen geöffnet ist oder nicht.

Diese Richtungen sind so ähnlich, wie ein langer CSS -Selektor oder XPath als Locator verwendet wird. Es ist spröde - und es ist die „schlechte Art von Sprödigkeit“. Wenn das gelbe Haus neu gestrichen wird und Sie die Schritte wiederholen, können Sie das Tor nicht mehr finden und sich möglicherweise entscheiden, aufzugeben (oder in diesem Fall schlägt der Test fehl).

Wenn Sie nichts über die Ziegensituation der Mutter der Mutter von Mike wissen, können Sie nicht an der richtigen Referenzstelle anhalten, um zu wissen, welches Tor Sie überprüfen sollten. Genau das macht die „schlechte Art von spröden“ schlecht - der Test kann aus allen möglichen Gründen brechen, und keiner dieser Gründe hat etwas mit der Benutzerfreundlichkeit des Tors zu tun.

Lassen Sie uns also einen anderen Front-End-Test durchführen, der viel stabiler ist. Immerhin sollen alle Tore auf einer bestimmten Straße in diesem Bereich einzigartige Seriennummern vom Hersteller haben:

Gehen Sie mit der Seriennummer 1234 zum Tor und überprüfen Sie, ob es sich öffnet.

Dies ist eher so, als würde man ein Element durch seine ID lokalisieren. Es ist stabiler und es ist nur ein Schritt. Alle Fehlerpunkte des letzten Tests wurden entfernt. Dieser Test schlägt nur dann fehl, wenn das Tor mit dieser ID nicht wie erwartet geöffnet wird.

Nun, wie sich herausstellt, obwohl keine zwei Tore den gleichen Ausweis auf derselben Straße haben sollten , ist dies nirgendwo und eines Tages ein weiteres Tor auf der Straße mit dem gleichen Ausweis.

Wenn der neu eingestellte Gate -Inspektor das nächste Mal „Gate 1234“ testet, finden sie das andere zuerst und besuchen jetzt das falsche Haus und überprüfen das Falsche. Der Test könnte scheitern oder schlimmer: Wenn dieses Tor wie erwartet funktioniert, wird der Test immer noch bestehen, aber es wird nicht das beabsichtigte Subjekt getestet. Es bietet falsches Vertrauen. Es würde weiterhin vorbei sein, wenn unser ursprüngliches Zieltor mitten in der Nacht von Tordieben gestohlen würde.

Nach einem solchen Vorfall ist klar, dass IDs nicht so stabil sind, wie wir dachten. Wir denken also einige Nachdenken auf der nächsten Ebene und entscheiden, dass wir im Inneren des Tors eine besondere ID nur zum Testen wünschen. Wir werden eine Technologie aussenden, um die spezielle ID nur dieses einen Tor zu setzen. Die neuen Testanweisungen sehen so aus:

Gehen Sie mit dem Test-ID „My-Favorit-Gate“ zum Tor und prüfen Sie, ob es sich öffnet.

Dieser ist wie die Verwendung des beliebten Daten-Test-Attributs. Attribute wie diese sind großartig, da es in dem Code offensichtlich ist, dass sie für automatisierte Tests verwendet werden und nicht geändert oder entfernt werden sollten. Solange das Tor dieses Attribut hat, werden Sie immer das Tor finden. Genau wie IDS ist die Einzigartigkeit immer noch nicht durchgesetzt, aber es ist etwas wahrscheinlicher.

Dies ist ungefähr so ​​weit weg von spröden, wie Sie können, und es bestätigt die Funktionalität des Tors. Wir sind auf nichts abhängig, außer dem Attribut, das wir absichtlich zum Testen hinzugefügt haben. Aber hier versteckt sich ein bisschen Probleme ...

Dies ist ein Benutzeroberfläche für das Gate, aber der Locator ist etwas, das kein Benutzer jemals verwenden würde, um das Gate zu finden.

Es ist eine verpasste Gelegenheit, denn in diesem imaginären Landkreis stellt sich heraus, dass die Tore erforderlich sind, um die Hausnummer auf sie auszudrucken, damit die Leute die Adresse sehen können. Alle Tore sollten also ein einzigartiges vom Menschen ausgerichteter Label haben, und wenn sie es nicht tun, ist es an und für sich ein Problem.

Wenn sich das Tor mit der Test -ID befindet, würde unser Test immer noch bestehen, wenn sich herausstellt, dass das Tor neu gestrichen wurde und die Hausnummer vertuscht wurde. Aber der springende Punkt des Tores ist, dass Menschen auf das Haus zugreifen. Mit anderen Worten, ein funktionierendes Tor , das ein Benutzer nicht finden kann, sollte immer noch ein Testfehler sein, und wir möchten, dass ein Locator, der dieses Problem aufdecken kann.

Hier ist ein weiterer Pass bei diesem Testanweis für den Gate Inspector am ersten Tag:

Gehen Sie zum Tor für die Hausnummer 40 und prüfen Sie, ob es sich öffnet.

Dieser verwendet einen Locator, der dem Test einen Mehrwert verleiht : Es hängt von etwas ab, von dem Benutzer auch abhängig sind. Dies ist das Etikett für das Gate. Es fügt einen potenziellen Grund hinzu, warum der Test scheitert, bevor er die Interaktion erreicht, die wir tatsächlich testen möchten, was auf den ersten Blick schlecht erscheinen könnte. Aber in diesem Fall, weil der Locator aus Sicht eines Benutzers aussagekräftig ist, sollten wir dies nicht als „spröde“ zuckern. Wenn das Tor nicht von seinem Etikett gefunden werden kann, spielt es keine Rolle, ob es sich öffnet oder nicht - dies ist die „gute Art von Sprödigkeit“.

Die DOM ist wichtig

Viele Front-End-Testberatung geben uns auf, zu vermeiden, dass Lokatoren geschrieben werden, die von der DOM-Struktur abhängen. Dies bedeutet, dass Entwickler im Laufe der Zeit Komponenten und Seiten neu aufstellen können und die Tests bestätigen können, dass Benutzer-Workflows nicht unterbrochen werden, ohne Tests zu aktualisieren, um die neue Struktur nachzuholen. Dieses Prinzip ist nützlich, aber ich würde es ein wenig optimieren, um zu sagen, dass wir es vermeiden sollten, Loker zu schreiben, die in unseren Front-End-Tests von irrelevanten Dom-Struktur abhängen.

Damit eine Anwendung korrekt funktioniert, sollte das DOM die Art und Struktur des Inhalts widerspiegeln, der zu einem bestimmten Zeitpunkt auf dem Bildschirm steht. Ein Grund dafür ist die Zugänglichkeit. Ein DOM, das in diesem Sinne korrekt ist, ist für die assistive Technologie viel einfacher, ordnungsgemäß zu analysieren und Benutzern zu beschreiben, die nicht den vom Browser gerenderten Inhalt sehen. DOM -Struktur und einfache alte HTML verändern einen großen Unterschied für die Unabhängigkeit von Benutzern, die sich auf assistive Technologie verlassen.

Lassen Sie uns einen Front-End-Test verbessern, um etwas an die Kontaktform unserer App einzureichen. Wir werden dafür Cypress verwenden, aber die Prinzipien der Auswahl der Locators gelten strategisch für alle Front-End-Test-Frameworks, die das DOM zum Auffinden von Elementen verwenden. Hier finden wir Elemente, geben einen Test ein, senden das Formular ein und überprüfen, ob der Zustand „Danke“ erreicht ist:

 //? Nicht empfohlen
cy.get ('#name'). type ('mark')
Cy.get ('#Kommentar'). Typ ('Testkommentar')
Cy.get ('. Subjekt-BTN'). Click ()
Cy.get ('. Danke'). Sollte ('Be.visible')

In diesen vier Zeilen gibt es alle möglichen impliziten Behauptungen. cy.get () prüft, dass das Element im DOM existiert. Der Test fällt fehl, wenn das Element nach einer bestimmten Zeit nicht vorhanden ist, während Aktionen wie Typ und Klicken Sie aufsuchen, ob die Elemente sichtbar, aktiviert und von etwas anderem vor dem Einführung einer Aktion sichtbar sind.

Wir erhalten also auch in einem einfachen Test wie diesem viel „kostenlos“, aber wir haben auch einige Abhängigkeiten von Dingen eingeführt, die wir (und unsere Benutzer) nicht wirklich interessieren. Die spezifische ID und Klassen, die wir überprüfen, scheinen stabil genug zu sein, insbesondere im Vergleich zu Selektoren wie Div.main> P: N-Child (3)> span.is-a-Button oder was auch immer. Diese langen Selektoren sind so spezifisch, dass eine geringfügige Änderung des DOM dazu führen kann, dass ein Test fehlschlägt, da es das Element nicht finden kann , nicht weil die Funktionalität unterbrochen ist.

Aber auch unsere kurzen Selektoren haben wie #Name drei Probleme:

1. Die ID kann im Code geändert oder entfernt werden, wodurch das Element übersehen wird, insbesondere wenn das Formular mehr als einmal auf einer Seite angezeigt wird. Für jede Instanz muss möglicherweise eine eindeutige ID generiert werden, und das können wir nicht leicht in einen Test vorab füllen.
2. Wenn mehr als eine Instanz eines Formulars auf der Seite vorhanden ist und sie die gleiche ID haben, müssen wir entscheiden, welches Formular wir ausfüllen sollten.
3. Wir kümmern uns eigentlich nicht darum, was die ID aus der Sicht der Benutzer stammt, daher sind alle integrierten Behauptungen irgendwie… nicht vollständig gehebelt?

Bei Problemen eins und zwei besteht die empfohlene Lösung häufig darin, dedizierte Datenattribute in unserer HTML zu verwenden, die ausschließlich zum Testen hinzugefügt werden. Dies ist besser, da unsere Tests nicht mehr von der DOM-Struktur abhängen und als Entwickler den Code um eine Komponente umsetzt, werden die Tests weiter bestehen, ohne dass ein Update benötigt wird, solange sie den Data-Test = "Namensfeld" an das richtige Eingabelement halten.

Dies ist jedoch nicht mit Problem drei angesprochen-wir haben immer noch einen Front-End-Interaktionstest, der von etwas abhängt, das für den Benutzer bedeutungslos ist.

Sinnvolle Locators für interaktive Elemente

Element -Locators sind aussagekräftig, wenn sie von etwas abhängen, von dem wir tatsächlich abhängig sind , weil etwas über den Locator für die Benutzererfahrung wichtig ist. Bei interaktiven Elementen würde ich argumentieren, dass der beste Selektor der zugängliche Name des Elements ist. So etwas ist ideal:

 //? Empfohlen
Cy.GetBylabeltext ('Name'). Typ ('mark')

In diesem Beispiel wird der Bylabeltext -Helfer aus der Cypress -Testbibliothek verwendet. (Wenn Sie die Testbibliothek in irgendeiner Form verwenden, hilft es Ihnen wahrscheinlich bereits dabei, zugängliche Locators wie diese zu schreiben.)

Dies ist nützlich, da jetzt die integrierten Überprüfungen (die wir über den Befehl Cy.Type () kostenlos erhalten) die Zugänglichkeit des Formularfelds enthalten. Alle interaktiven Elemente sollten über einen zugänglichen Namen verfügen, der der assistiven Technologie ausgesetzt ist. Auf diese Weise würde beispielsweise ein Screenreader -Benutzer wissen, in welchen Formular das Formular erstellt, in das er eingeben, um die erforderlichen Informationen einzugeben.

Die Möglichkeit, diesen zugänglichen Namen für ein Formularfeld anzugeben, erfolgt normalerweise über ein Etikettelement, das dem Feld durch eine ID zugeordnet ist. Der Befehl getbyLabeltext aus der Cypress Testing Library überprüft, ob das Feld angemessen gekennzeichnet ist, aber auch, dass das Feld selbst ein Element ist, das ein Etikett haben darf. Zum Beispiel würde der folgende HTML -Befehl zum Beispiel korrekt fehlschlagen, da das Beschriftung eines Div -Kennzeichnungen jedoch ungültig ist.

 
<label f> editable DIV-Element: </label>
<div intdlichung="true"></div>

Da dies ungültig ist, könnte die ScreenReader -Software dieses Etikett dieses Feld niemals korrekt in Verbindung bringen. Um dies zu beheben, würden wir das Markup aktualisieren, um ein echtes Eingabelement zu verwenden:

 
<label f> Realeingabe: </label>
<eingabe type="text"></eingabe>

Das ist großartig. Wenn der Test an diesem Punkt nach Änderungen an das DOM fehlschlägt, liegt dies nicht an einer irrelevanten Strukturänderung, wie Elemente angeordnet sind, sondern weil unsere Änderungen etwas unternommen haben, um einen Teil von DOM zu brechen , dass unsere Front-End-Tests ausdrücklich für die Benutzer von Bedeutung sind.

Sinnvolle Locators für nicht interaktive Elemente

Für nicht interaktive Elemente sollten wir unsere Denkkappen anziehen. Lassen Sie uns ein wenig Urteilsvermögen verwenden, bevor wir auf die Data-CY- oder Daten-Test-Attribute zurückgreifen, die für uns immer da sein werden, wenn die DOM überhaupt keine Rolle spielt.

Bevor wir uns in die generischen Locators eintauchen, denken wir daran: Der Zustand des Dom ist unser Ganzes ™ als Webentwickler (zumindest denke ich). Und das DOM fährt die UX für alle, die die Seite nicht visuell erleben. In den meisten Fällen kann es ein sinnvolles Element geben, das wir in dem Code verwenden könnten oder sollten, den wir in einen Test -Locator aufnehmen können.

Und wenn es nicht gibt, weil. Angenommen, der Anwendungscode ist alles generische Container wie Div und Span. Wir sollten in Betracht ziehen, den Anwendungscode zuerst zu beheben, während wir den Test hinzufügen. Andernfalls besteht die Gefahr, dass unsere Tests tatsächlich festlegen , dass die generischen Container erwartet und gewünscht werden, was es für jemanden etwas schwieriger macht, diese Komponente so zu ändern, dass er zugänglicher ist.

Dieses Thema eröffnet eine Dose Würmer darüber, wie die Zugänglichkeit in einer Organisation funktioniert. Wenn niemand darüber spricht und es nicht Teil der Praxis in unseren Unternehmen ist, nehmen wir als Front-End-Entwickler die Zugänglichkeit nicht ernst. Aber am Ende des Tages sollen wir die Experten in dem „richtigen Aufschlag“ für Design sein und was wir in Betracht ziehen sollten, um das zu entscheiden. Ich diskutiere diese Seite von Dingen viel mehr in meinem Vortrag von Connect.Tech 2021 mit dem Titel „Nachforschungen und Schreiben von zugänglichem Vue… Dingen“.

Wie wir oben gesehen haben, gibt es mit den Elementen, die wir traditionell als interaktiv betrachten, eine ziemlich gute Faustregel, die in unsere Front-End-Tests leicht zu aufbauen ist: Interaktive Elemente sollten wahrnehmbare Beschriftungen haben, die korrekt mit dem Element verbunden sind. Wenn wir es testen, sollte alles, was interaktiv ist, mithilfe dieser erforderlichen Beschriftung aus dem DOM ausgewählt werden.

Für Elemente, die wir nicht als interaktiv betrachten-wie die meisten inhaltsrenderen Elemente, die Textstücke von allem anzeigen, abgesehen von einigen grundlegenden Sehenswürdigkeiten wie Main-würden wir keine Leuchtthouse-Prüfungsfehler auslösen, wenn wir den Großteil unseres nicht interaktiven Inhalts in generische Div- oder Span-Container einfügen. Das Markup ist jedoch nicht sehr informativ oder hilfreich für die assistive Technologie, da es nicht die Art und Struktur des Inhalts für jemanden beschreibt, der es nicht sehen kann. (Um dies extrem zu sehen, schauen Sie sich den hervorragenden Blog -Beitrag von Manuel Matuzovic an: „Erstellen Sie die unzugängliche Website mit einem perfekten Leuchtturm -Punktzahl.)

In dem HTML, den wir rendern, vermitteln wir wichtige Kontextinformationen an jeden, der den Inhalt nicht visuell wahrnimmt. Mit dem HTML wird das DOM erstellt, das DOM wird verwendet, um den Browser -Barrierefreiheitsbaum zu erstellen, und der Barrierefreiheitstaum ist die API, mit der assistive Technologien aller Art verwendet werden können, um die Inhalte und die Aktionen auszudrücken, die mit unserer Software an eine behinderte Person übernommen werden können. Ein Screenreader ist häufig das erste Beispiel, an das wir denken, aber der Barrierefreiheitstaum kann auch von anderen Technologien verwendet werden, z. B. Anzeigen, die unter anderem Webseiten in Braille verwandeln.

Bei automatisierten Barrierefreiheitsprüfungen werden uns nicht angegeben, ob wir wirklich die richtige HTML für den Inhalt erstellt haben. Die „Richtigkeit“ der HTML -Einberufung. Wir machen Entwickler darüber, welche Informationen, von denen wir glauben, dass sie im Breacing -Baum mitgeteilt werden müssen.

Sobald wir diesen Anruf getätigt haben, können wir entscheiden, wie viel davon für die automatisierten Front-End-Tests geeignet ist.

Nehmen wir an, wir haben beschlossen, dass ein Container mit der Status -Aria -Rolle das „Dankeschön“ und die Fehlermeldung für ein Kontaktformular enthält. Dies könnte schön sein, damit das Feedback für den Erfolg oder das Misserfolg des Formulars von einem Screenreader bekannt gegeben werden kann. CSS-Klassen von. Danke und .Eror könnten angewendet werden, um den visuellen Zustand zu steuern.

Wenn wir dieses Element hinzufügen und einen UI -Test dafür schreiben möchten, können wir eine solche Behauptung schreiben, nachdem der Test das Formular ausfüllt und sie einreicht:

 //? Nicht empfohlen
Cy.get ('. Danke'). Sollte ('Be.visible')

Oder sogar einen Test, der einen nicht breiten, aber immer noch bedeutungslosen Selektor wie diesen verwendet:

 //? Nicht empfohlen
Cy.get ('[Data-Test]'). sollte ('Be.visible')

Beide könnten mit Cy.Contains () neu geschrieben werden:

 //? Empfohlen
cy.contains ('[rollen = "status"]', 'Danke, wir haben deine Nachricht erhalten' ').
  . sollte ('be.visible')

Dies würde bestätigen, dass der erwartete Text erschien und sich in der richtigen Art von Container befand. Im Vergleich zum vorherigen Test weist dies viel mehr Wert auf die Überprüfung der tatsächlichen Funktionalität auf. Wenn ein Teil dieses Tests fehlschlägt, möchten wir es wissen, da sowohl die Nachricht als auch der Element -Selektor für uns wichtig sind und nicht trivial geändert werden sollten.

Wir haben hier definitiv eine Berichterstattung ohne viel zusätzlichen Code erhalten, aber wir haben auch eine andere Art von Sprödigkeit eingeführt. Wir haben einfache englische Saiten in unseren Tests, und das bedeutet, wenn sich die Nachricht „Danke“ zu so etwas wie „Danke, dass Sie sich angeregt haben!“ Ändert Dieser Test scheitert plötzlich. Gleiches gilt für alle anderen Tests. Eine kleine Änderung, wie ein Etikett geschrieben wurde, müsste alle Tests aktualisieren, die auf Elemente mit dieser Etikett abzielen.

Wir können dies verbessern, indem wir die gleiche Wahrheitsquelle für diese Saiten in Front-End-Tests verwenden wie in unserem Code. Und wenn wir derzeit in der HTML unserer Komponenten eine menschliche lesbare Sätze eingebettet haben, haben wir jetzt einen Grund, dieses Zeug dort herauszuziehen.

Menschliche lesbare Saiten könnten die magische Anzahl von UI-Code sein

Eine magische Zahl (oder weniger aufermaßen, eine „ungenannte namens numerische Konstante“) ist der superspezifische Wert, den Sie manchmal im Code sehen, der für das Endergebnis einer Berechnung wichtig ist, wie ein gutes altes 1.023033 oder so. Aber da diese Zahl nicht nicht veröffentlicht ist, ist ihre Bedeutung unklar und daher ist unklar, was sie tut. Vielleicht gilt es eine Steuer. Vielleicht kompensiert es einen Fehler, von dem wir nichts wissen. Wer weiß?

In jedem Fall gilt das Gleiche für Front-End-Tests, und der allgemeine Rat ist, magische Zahlen aufgrund ihrer mangelnden Klarheit zu vermeiden. Code -Bewertungen fangen sie häufig auf und fragen, wofür die Nummer ist. Können wir es in eine Konstante bewegen? Wir tun auch dasselbe, wenn ein Wert mehrerer Stellen wiederverwendet werden soll. Anstatt den Wert überall zu wiederholen, können wir ihn in einer Variablen speichern und die Variable nach Bedarf verwenden.

Wenn ich im Laufe der Jahre Benutzeroberflächen schreibe, habe ich den Textinhalt in HTML- oder Vorlagendateien als sehr ähnlich wie Magnummern in anderen Kontexten angezeigt. Wir legen absolute Werte durch unseren Code, aber in Wirklichkeit ist es möglicherweise nützlicher, diese Werte an anderer Stelle zu speichern und sie zur Bauzeit (oder sogar durch eine API abhängig von der Situation) zu bringen.

Dafür gibt es einige Gründe:

1. Ich habe mit Kunden zusammengearbeitet, die alles von einem Content -Management -System steuern wollten. Inhalte, sogar Bildschriften und Statusnachrichten, die nicht im CMS lebten, sollten vermieden werden. Clients wollten eine vollständige Kontrolle, so dass Inhalte Änderungen nicht benötigten, um den Code zu bearbeiten und die Site neu abzulegen. Das macht Sinn; Code und Inhalt sind unterschiedliche Konzepte.
2. Ich habe in vielen mehrsprachigen Codebasen gearbeitet, bei denen der gesamte Text durch einige Internationalisierungsrahmen wie folgt gezogen werden muss:

 <label f>
  
  {{{content [currentLuage] .contactform.name}}
</label>

3. Was die Front-End-Tests betrifft, sind unsere UI-Tests viel robuster, wenn wir, anstatt nach einer bestimmten "Danke" -Meldung zu suchen, in den Test zu suchen, so etwas wie folgt:

 const text = content.en.contactfrom // wir würden dies einmal machen und alle Tests in der Datei können daraus lesen

cy.contains (text.namelabel, '[rollen = "status"]). sollte (' be.visible ')

Jede Situation ist anders, aber ein System von Konstanten für Strings ist ein großes Gut beim Schreiben robuster UI -Tests, und ich würde es empfehlen. Wenn und wenn Übersetzung oder dynamische Inhalte für unsere Situation notwendig werden, sind wir viel besser darauf vorbereitet.

Ich habe auch gute Argumente gegen den Importieren von Textzeichenfolgen in Tests gehört. Beispielsweise sind einige Fund -Tests lesbarer und im Allgemeinen besser, wenn der Test selbst den erwarteten Inhalt unabhängig von der Inhaltsquelle angibt.

Es ist ein fairer Punkt. Ich bin weniger davon überzeugt, weil ich denke, dass Inhalte durch ein redaktionelles Überprüfungs-/Veröffentlichungsmodell kontrolliert werden sollten, und ich möchte, dass der Test überprüft, ob der erwartete Inhalt der Quelle gerendert wurde, und nicht bestimmte Zeichenfolgen, die bei geschriebenen Test korrekt waren. Aber viele Leute sind mir nicht einverstanden, und ich sage, solange der Kompromiss in einem Team verstanden wird, ist jede Wahl akzeptabel.

Trotzdem ist es immer noch eine gute Idee, Code von Inhalten im vorderen Ende allgemeiner zu isolieren. Und manchmal kann es sogar gültig sein, sich zu mischen und zu übereinstimmen-wie beim Importieren von Zeichenfolgen in unseren Komponententests und nicht in unseren End-to-End-Tests. Auf diese Weise sparen wir etwas Duplizierung und gewinnen Vertrauen, dass unsere Komponenten korrekte Inhalte anzeigen und gleichzeitig Front-End-Tests durchführen, die den erwarteten Text unabhängig im redaktionellen, benutzergerichteten Sinne behaupten.

Wann werden Datentest-Locators verwendet

CSS-Selektoren wie [data-test = "Success-Message"] sind immer noch nützlich und können sehr hilfreich sein, wenn sie auf absichtliche Weise verwendet werden, anstatt die ganze Zeit zu verwenden. Wenn wir beurteilen, dass es keine aussagekräftige, zugängliche Möglichkeit gibt, ein Element abzuzielen, sind Datentestattribute immer noch die beste Option. Sie sind viel besser als beispielsweise, abhängig von einem Zufall wie der Dom -Struktur, an dem Sie den Test schreiben, und zurück auf den Test „Second List in der dritten Div mit einer Kartenklasse“ -Teststil zurückzuführen.

Es gibt auch Zeiten, in denen der Inhalt dynamisch sein wird und es keine Möglichkeit gibt, Strings aus einer gewöhnlichen Quelle der Wahrheit zu schnappen, die in unseren Tests verwendet werden kann. In diesen Situationen hilft uns ein Data-Test-Attribut, das spezifische Element zu erreichen, das uns wichtig ist. Es kann weiterhin mit einer barrierefreundlichen Behauptung kombiniert werden, beispielsweise:

 Cy.get ('H2 [Data-test = "Intro-Subheading"]'))

Hier möchten wir herausfinden, was das Data-Test-Attribut der Intro-Sub-Heading hat, aber wir können unseren Test dennoch behaupten, dass es sich um ein H2-Element handeln sollte, wenn wir dies erwarten. Das Data-Test-Attribut wird verwendet, um sicherzustellen, dass wir das spezifische H2 erhalten, an dem wir interessiert sind, nicht an einem anderen H2, das auf der Seite möglicherweise auf der Seite steht, wenn der Inhalt dieses H2 zum Zeitpunkt des Tests nicht bekannt ist.

Selbst in Fällen, in denen wir den Inhalt kennen, verwenden wir möglicherweise Datenattribute, um sicherzustellen, dass die Anwendung diesen Inhalt an der richtigen Stelle bringt:

 Cy.Contains ('H2 [Data-Test = "Intro-Subheading"]', 'Willkommen zum Testen!')

Daten-Test-Selektoren können auch ein Komfort sein, um zu einem bestimmten Teil der Seite zu gelangen und dann Aussagen in diesem Bereich zu erlassen. Dies könnte wie Folgendes aussehen:

 Cy.get ('Artikel [data-test = "Ablum-Card-Blur-Great-Eskape"]'). Innere () => {
  Cy.Contains ('H2', 'The Great Escape'). Sollte ('be.
  Cy.Contains ('P', '1995 Album von Blur'). Sollte ('Be.visible')
  Cy.get ('[data-test = "sterne"]'). sollte ('Have.Length', 5)
})

Zu diesem Zeitpunkt geraten wir eine Nuance, weil es möglicherweise andere gute Möglichkeiten gibt, auf diesen Inhalt abzuzielen. Es ist nur ein Beispiel. Aber am Ende des Tages ist es eine gute, wenn Sie sich über solche Details sorgen, ist, wo wir zumindest das Verständnis für die in der HTML eingebetteten Barrierefunktionen haben, die wir testen, und dass wir diese in unsere Tests einbeziehen möchten.

Wenn das DOM wichtig ist, testen Sie es

Front-End-Tests bringen uns viel mehr Wert, wenn wir nachdenklich darüber nachdenken, wie wir den Tests sagen, mit welchen Elementen wir interagieren und mit welchen Inhalten wir zu erwarten sind. Wir sollten zugängliche Namen bevorzugen, um interaktive Komponenten abzuzielen, und wir sollten bestimmte Elementnamen, ARIA-Rollen usw. für nicht interaktive Inhalte einfügen-wenn diese Dinge für die Funktionalität relevant sind. Diese Locators erzeugen, wenn sie praktisch sind, die richtige Kombination aus Stärke und Sprödigkeit.

Und natürlich gibt es für alles andere Datentest.

Das obige ist der detaillierte Inhalt vonMaximieren Sie Ihre Front-End-Test-Locators. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!