Elftklässler oder Testen von Layoutfehlern



    Im modernen Web wird zumindest einigen automatisierten UI-Tests zu Unrecht wenig Aufmerksamkeit geschenkt. Dies gilt insbesondere für den statischen Satz. Beim 2GIS Online- Projekt haben wir versucht, diese Lücke teilweise zu schließen. Welche bewährten Verfahren wir erworben haben und welche guten Bibliotheken wir kennengelernt haben, wird später beschrieben.

    Layout


    Betrachten Sie die Geschichte einer erfundenen



    Schaltfläche : Eine quadratische Schaltfläche mit einem Symbol. Alles ist einfach. Bemaßungen können in Pixel fest codiert werden - was ist der Unterschied?

    Fast sofort beginnt sich der Knopf zu entwickeln. Benutzer klicken selten auf eine Schaltfläche. Was tun? Fügen Sie optional eine erklärende Inschrift hinzu. Es bleibt nur eine geringfügige Vergrößerung der Breite, damit die Inschrift enthalten ist:



    Aber was ist mit der Inschrift in russischer Sprache? Ja, und der Originaltext kann sich ändern. Sie können die Breite also nicht fest codieren, sondern müssen sie beliebig ausführen: Es



    kann so viel Text enthalten, dass er nicht in einer Zeile gelesen werden kann. Es ist notwendig, die maximale Breite zu begrenzen und die Höhe zu lösen: Der



    Knopf wird noch wenig benutzt! Sie können eine zusätzliche mehrzeilige Beschreibung erstellen. Fügen Sie dazu eine Spanne mit den entsprechenden Stilen hinzu:



    Es scheint, dass alles berücksichtigt wurde und niemand dieses Layout brechen kann. Niemand außer dem elften Schüler - ein langes Wort, das nicht in die maximale Breite passt. Wir machen nur die Rechtschreibung:



    Benutzer begannen sich über den obsessiven großen Knopf zu beschweren, daher wurde beschlossen, ein Kreuz zu machen, das den Knopf schließt, ohne ihn tatsächlich zu drücken. Ein paar Stile für das Kreuz, ein kleiner Einzug für die Überschrift, damit sie nicht unter dieses Kreuz fällt - und Sie sind fertig:



    Vergessen Sie nicht, dass der Haupttext möglicherweise nicht vorhanden ist. Bearbeiten Sie den Einzug:



    Jetzt haben wir anscheinend eine Multifunktionsschaltfläche für alle Gelegenheiten mit behobenen Fehlern. richtig? Lassen Sie uns alle Fälle noch einmal zur gleichen Zeit sehen:



    Was sehen wir? Anstelle einer voll funktionsfähigen Schaltfläche sehen wir eine Fülle von Regressionsfehlern: Das Symbol fiel aus der Schaltfläche heraus, die vertikale Ausrichtung brach, eine zusätzliche Einkerbung erschien für das Kreuz ... Mit anderen Worten, sie wollten das Beste, es stellte sich wie immer heraus.

    Stellen Sie sich nun vor, es geht nicht um einen Knopf, sondern um ein großes, sich ständig weiterentwickelndes Projekt mit einem Publikum von mehreren Millionen Dollar. Support wird zur Hölle, in der leider viele Layouter leben.

    Es gibt viele Techniken und Methoden, die das Layout komplexer Projekte unterstützen. Zum Beispiel das bekannte BEM, das wir auch verwenden. Die BEM-Methodik allein löst jedoch nicht die Fehler beim Regressionstyp, sondern lokalisiert sie nur. Wie kann man sie im Prinzip loswerden? Es ist eigentlich sehr einfach (und dafür müssen Sie nicht die API eines Dutzend neuer JS-Bibliotheken lernen!) - Sie müssen eine Test-HTML-Seite mit allen Schaltflächenzuständen erstellen. Lassen Sie es uns jetzt gemeinsam erstellen. Es dauert nicht länger als 10 Sekunden. Hier ist sogar das Markup:

    Test page

    Keine js, npm-Abhängigkeiten, Express-Server ... Nur eine im Browser geöffnete HTML-Datei.

    Für jede evolutionäre Iteration müssen ein oder mehrere neue Zustände (dh Varianten des HTML-Codes des zu testenden Elements, einschließlich des Inhalts) erstellt, aber nicht gelöscht werden. Das Anzeigen aller alten Bedingungen kann als halbautomatische Regression bezeichnet werden.

    Wir werden aus zwei Gründen bewusst keine Mittel zur Automatisierung dieser Arbeit empfehlen: Erstens kann (und sollte) in den meisten Fällen jedes Front-End eine solche Seite für sich erstellen. Zweitens schreiben wir für komplexe Fälle und pixelgenaue Fälle unsere eigene Lösung, die wir noch nicht bekannt geben können.

    Elfter Schüler


    Mehr als die Hälfte der Layoutfehler ist mit einer sehr einfachen Fehleinschätzung verbunden: Das Front-End berücksichtigt nicht, dass im Allgemeinen Text in die Textknoten seines Layouts fallen kann. Es kann mehrzeilig sein, aus langen Wörtern bestehen oder eine leere Zeichenfolge sein.

    Nehmen Sie ein paar Ihrer Layouts - ich wette auf den russischen Rubel, dass sogar ein Elftklässler sie brechen kann . Fügen Sie in jedes Feld ein paar Elftklässler ein - Layoutbruch garantiert!

    Ich schlage vor, eine beliebte Site zu öffnen und den folgenden Code im Debugger auszuführen

    var a,w=document.createTreeWalker(document,NodeFilter.SHOW_TEXT);while(a=w.nextNode()){if(a.textContent.trim().length)a.textContent='Одиннадцатиклассница пошла посмотреть на достопримечательность, она шла долго, несколько строчек, пока не пришла'}

    Die ersten zehn Websites, die mir in den Sinn kamen (natürlich ohne 2GIS Online), waren so kaputt, dass es absolut unmöglich wurde, sie zu verwenden.

    Dies bedeutet natürlich nicht, dass der elfte Schüler jeden Tag alle Internet-Textknoten durchläuft und das Layout bricht (mit dem gleichen Erfolg kann die Site vor Ebavavirus geschützt werden), aber Sie müssen die folgenden Faktoren berücksichtigen:

    1. Wenn Ihr Projekt in mehreren Sprachen existiert, kann es in einer anderen Sprache einen längeren Satz geben (Russisch ist länger als Englisch, Spanisch ist länger als Russisch usw.)
    2. Der Benutzer verfügt möglicherweise nicht über die Hauptschriftart, und der Fallback ist größer
    3. Der Benutzer verfügt möglicherweise über einen benutzerdefinierten Zoom oder eine andere Schriftwiedergabe-Engine.
    4. Der Text kann während des Support-Prozesses geändert werden, auch von Content-Managern, die das Layout mit Sicherheit nicht überprüfen
    5. Falscher Text kann einfach aufgrund eines Fehlers im js-Code ins Feld fliegen
    6. Ein Fehler im Layout eines anderen Blocks kann Ihren Block quetschen
    7. Jemand wird diesen Artikel lesen und den Code im Debugger ausführen :)

    Wir sind der festen Überzeugung, dass in jedem dieser Fälle der gesamte Text für den Benutzer sichtbar und lesbar sein sollte. Es kann die Blockgröße unkritisch ändern, zum Überblenden gehen oder mit einem Auslassungszeichen abbrechen. aber es sollte sich nicht in ein Monster verwandeln, das benachbarte Knoten angreift und die Augen des Benutzers ausbrennt; das heißt, zumindest sollte es nicht in einen anderen Text passen.

    Automatisierung


    Alles, was wir oben geschrieben haben, kann nicht als automatisches Testen bezeichnet werden, da es das menschliche Auge erfordert. Wenn Sie Ihre Augen überhaupt nicht belasten möchten, helfen Ihnen die Tests, die wir Dom-Tests nennen.

    Dom-Test ist ein js-Code, der in einem Browser ausgeführt wird und etwas im isolierten Teil der Anwendung oder in der gesamten Anwendung überprüft. Alles kann überprüft werden: vom Vorhandensein der Klasse und des Attributs in HTML bis zu den Argumenten, mit denen eine Funktion aufgerufen wurde, einschließlich asynchron.

    Hier finden Sie so wunderbare Bibliotheken wie:

    Mokka . Testrahmen. Ermöglicht das Erstellen von Tests und Testgruppen, einschließlich asynchroner Tests. Führen Sie vor und nach einem Test oder einer Gruppe von Tests Code aus.

    Chai. Bibliothek zum Durchsetzen. Im Prinzip können Sie die native assert node.js verwenden, aber der "Tee" hat einige Extras, zum Beispiel das schöne diff deepEqual.

    sinon . Eine Bibliothek, mit der Sie zwei wichtige Dinge tun können:

    • Behalten Sie den Überblick über Funktionen. Sie werden wissen, wie oft und mit welchen Argumenten die Funktion aufgerufen wurde, der Sie folgen.
    • FakeTimers. Ermöglicht das Ersetzen von setTimeout und setInterval und damit das Verwalten der Zeit. Das heißt, nach der Ersetzung können Sie sinon.tick (20) aufrufen - und 20 Millisekunden vergehen sofort, während alle für die Ausführung in diesem Zeitraum registrierten Zeitüberschreitungen ausgeführt werden.

    Wenn Sie all dies kombinieren, können Sie Tests sowohl für die gesamte Anwendung als auch für ihre isolierten Teile schreiben. In diesen Tests können Sie buchstäblich alles tun: Füllen Sie das Formular aus und klicken Sie auf die Schaltflächen. Dombaum ändern; Ajax-Anfragen stellen ... Tatsächlich befinden Sie sich in solchen Tests in der Debugging-Konsole des Browsers und haben in Ihren Händen alle js-Bibliotheken zum Testen, die Sie mögen.

    Der Vorteil solcher Tests besteht darin, dass sie in einem Browser ausgeführt werden. Dies bedeutet, dass sie in jedem Browser ohne Anpassungsressourcen ausgeführt werden können (was nicht über Selentreiber gesagt werden kann, insbesondere in Kombination mit beispielsweise ie8 oder Android 4.0). Darüber hinaus können solche Tests auf phantomJS im vollautomatischen Modus ausgeführt werden, beispielsweise an Git-Push-Hooks.

    Nur für den Fall, es ist erwähnenswert, dass Dom-Tests keine Alternative zu Regressionstests des Layouts sind. Dies ist nur ein weiterer Ansatz zum Schutz des Codes mit seinen eigenen Besonderheiten und seinem eigenen Umfang.

    Schlussfolgerungen


    Holen Sie sich eine HTML-Seite für die Layout-Regression, fügen Sie einen elften Grader hinzu , und Ihr Layout wird zehnmal besser. Schützen Sie Ihren Code mit js-tests, und Sie können die Dienste von Testern ablehnen (die sich erneut als Automatisierungsingenieure qualifizieren müssen und Ihnen beim Schreiben von Tests helfen müssen). Beim 2GIS Online-Projekt fallen 90% der Aufgaben ohne manuelle Tests in den Kampf, und dies war dank der oben genannten Testansätze weitgehend möglich.

    Warten Sie nicht, bis die elfte Klasse selbst zu Ihnen kommt!

    Weitere Informationen finden Sie in meiner Präsentation zu den Web Standards Days.

    Jetzt auch beliebt: