Entwickeln einer Benutzeroberfläche in JavaScript mithilfe von TDD-Prinzipien

StackOverflow https://stackoverflow.com/questions/96086

  •  01-07-2019
  •  | 
  •  

Frage

Ich hatte große Probleme damit, den besten Weg zu finden, die TDD-Prinzipien bei der Entwicklung der Benutzeroberfläche in JavaScript richtig zu befolgen.Wie geht man dabei am besten vor?

Ist es am besten, das Visuelle vom Funktionalen zu trennen?Entwickeln Sie zuerst die visuellen Elemente, schreiben Sie dann Tests und programmieren Sie dann die Funktionalität?

War es hilfreich?

Lösung

Ich habe in der Vergangenheit einige TDD mit Javascript durchgeführt und musste zwischen Unit- und Integrationstests unterscheiden.Selenium testet Ihre gesamte Site, mit der Ausgabe vom Server, seinen Postbacks, Ajax-Aufrufen und all dem.Aber für Unit-Tests ist das alles nicht wichtig.

Was Sie wollen, ist nur die Benutzeroberfläche, mit der Sie interagieren werden, und Ihr Skript.Das Werkzeug, das Sie hierfür verwenden werden, ist grundsätzlich JsUnit, das ein HTML-Dokument mit einigen Javascript-Funktionen auf der Seite übernimmt und diese im Kontext der Seite ausführt.Was Sie also tun, ist, den Stubbed-Out-HTML-Code mit Ihren Funktionen in die Seite einzufügen.Von dort aus können Sie die Interaktion Ihres Skripts mit den UI-Komponenten in der isolierten Einheit des simulierten HTML, Ihres Skripts und Ihrer Tests testen.

Das kann etwas verwirrend sein, also schauen wir mal, ob wir einen kleinen Test machen können.Gehen wir bei einigen TDD davon aus, dass nach dem Laden einer Komponente eine Liste von Elementen basierend auf dem Inhalt der LI gefärbt wird.

test.html

<html>
<head>
<script src="jsunit.js"></script>
<script src="mootools.js"></script>
<script src="yourcontrol.js"></script>
</head>
<body>
    <ul id="mockList">
        <li>red</li>
        <li>green</li>
    </ul>   
</body>
<script>
    function testListColor() {
        assertNotEqual( $$("#mockList li")[0].getStyle("background-color", "red") );

        var colorInst = new ColorCtrl( "mockList" );

        assertEqual( $$("#mockList li")[0].getStyle("background-color", "red") );
    }
</script>


</html>

Offensichtlich ist TDD ein mehrstufiger Prozess, daher benötigen wir für unsere Kontrolle mehrere Beispiele.

yourcontrol.js (Schritt 1)

function ColorCtrl( id ) {
 /* Fail! */    
}

yourcontrol.js (Schritt 2)

function ColorCtrl( id ) {
    $$("#mockList li").forEach(function(item, index) {
        item.setStyle("backgrond-color", item.getText());
    });
    /* Success! */
}

Sie können hier wahrscheinlich den Schwachpunkt erkennen: Sie müssen Ihr Schein-HTML hier auf der Seite mit der Struktur Ihrer Serversteuerungen synchron halten.Aber es bietet Ihnen ein schönes System für TDD'ing mit JavaScript.

Andere Tipps

Ich habe noch nie erfolgreich UI-Code TDDed. Die nächstgelegene wir kamen, war in der Tat zu separatem UI-Code, so viel wie möglich von der Anwendungslogik. Dies ist ein Grund, warum das Model-View-Controller-Muster ist nützlich -. Das Modell und Controller kann ohne viel Mühe TDDed und ohne zu kompliziert bekommen

Nach meiner Erfahrung wurde die Sicht immer links für unsere Anwenderakzeptanztests (wir schrieben Web-Anwendungen und unsere UATs verwendet Java Httpunit). Allerdings ist es auf dieser Ebene wirklich ein Integrationstest, ohne den Test-in-Isolationseigenschaft wir mit TDD wünschen. Aufgrund dieser Einrichtung hatten wir unsere Controller / Modellversuche / Code zuerst zu schreiben, dann die Benutzeroberfläche und entsprechende UAT. Allerdings habe ich in der Swing-GUI-Code habe das Schreiben in letzter Zeit, ich habe mit Stubs den GUI Code zu schreiben zunächst mein Design des vorderen Endes zu erkunden, bevor Sie mit dem Controller / Modell / API hinzugefügt. YMMV hier aber.

So zu wiederholen, ist der einzige Rat, den ich geben kann, ist, was Sie bereits zu ahnen scheint -. Trennen UI-Code aus Ihrer Logik so weit wie möglich und TDD sie

Ich habe die MVP Architektur als sehr geeignet für das Schreiben von prüfbaren UIs gefunden. Presenter und Modell Klassen können einfach 100% Einheit sein getestet. Sie müssen nur noch darum kümmern, die (das ist eine dumme, dünne Schicht nur sein soll, dass Ereignisse an den Presenter feuert) für UI-Tests (mit Selen usw.)

Beachten Sie, dass in der ich spreche mit MVP ganz im UI-Kontext, ohne notwendigerweise auf die serverseitige Kreuzung. Ihre UI kann seine eigenen Presenter und Modell haben, die vollständig auf der Client-Seite lebt. Der Moderator steuert die UI-Interaktion / Validierung usw. Logik, während das Modell Zustandsinformationen hält und bietet ein Portal an das Backend (wo man ein separates Modell haben kann).

Sie sollten auch einen Blick auf die Presenter Erste TDD-Technik.

Dies ist der Hauptgrund ist, ich auf das Google Web Toolkit schaltet ... ich entwickeln und testen in Java und haben eine vernünftige Erwartung, dass die kompilierte JavaScript auf einer Vielzahl von Browsern ordnungsgemäß funktioniert. Da TDD in erster Linie eine Unit-Test-Funktion ist, kann der größte Teil des Projekts entwickelt und vor der Kompilierung und Bereitstellung getestet werden.

Integration und Funktionstestsuiten überprüfen, dass der resultierende Code funktioniert wie erwartet, nachdem es zu einem Test-Server bereitgestellt wird.

Ich bin nur über das Tun Javascript TDD auf ein neues Projekt starten an dem ich arbeite. Mein aktueller Plan ist, zu verwenden, QUnit die Unit-Tests zu tun. Während die Tests entwickeln können, indem einfach die Aktualisierung der Testseite in einem Browser ausgeführt werden.

Für die kontinuierliche Integration (und die Gewährleistung der in allen Browsern laufen Tests), werde ich benutzen Selen automatisch laden Sie die Testumgebung in jedem Browser und das Ergebnis ablesen. Diese Tests werden laufen auf jeder checkin zur Quellcodeverwaltung.

Ich werde auch benutzen JSCoverage Code-Coverage-Analyse der Tests zu erhalten. Dies wird auch mit Selen automatisiert werden.

Ich bin zur Zeit in der Mitte dieser der Einrichtung. Ich werde diese Antwort mit genaueren Angaben aktualisieren, sobald ich das Setup gehämmert.

Testing Tools:

Was ich tue, ist der Dom zu stecken, um zu sehen, ob ich bekommen, was ich erwarte. Ein großer Nebeneffekt davon ist, dass die Tests schnell zu machen, können Sie auch Ihre Anwendung schnell machen.

Ich habe gerade ein Open-Source-Toolkit, das mit JavaScript tdd immens helfen. Es ist eine Zusammensetzung vieler Open-Source-Tools, die Ihnen eine Arbeits requirejs Rückgrat App aus dem Kasten heraus gibt.

Es einzelne Befehle zur Verfügung zu laufen: dev Web-Server, Jasmin einzige Browser-Test-Runner, Jasmin js-Test-Treiber Multi-Browser-Test Läufer und concatenization / Verkleinerungs für JavaScript und CSS. Es gibt auch eine unminified Version der App für die Produktion Debugging, Vorkompilierung Lenker Vorlagen und unterstützt Internationalisierung.

ist keine Einstellung erforderlich. Es funktioniert einfach.

http://github.com/davidjnelson/agilejs

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top