Entwickeln von UI in JavaScript mit TDD-Prinzipien

Ich hatte viele Schwierigkeiten, den besten Weg zu finden, TDD-Prinzipien bei der Entwicklung von UI in JavaScript richtig zu folgen. Was ist der beste Weg, dies zu tun?

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

0
hinzugefügt bearbeitet
Ansichten: 9

7 Antworten

0
hinzugefügt

Ich habe die MVP -Architektur als sehr geeignet für das Schreiben von testbaren UIs gefunden. Ihre Presenter und Model Klassen können einfach zu 100% getestet werden. Sie müssen sich nur um die Ansicht (die nur eine dumme, dünne Schicht sein sollte, die Ereignisse für den Presenter auslöst) um UI-Tests kümmern (mit Selenium usw.).

Beachten Sie, dass ich in der Rede von der Verwendung von MVP im UI-Kontext spreche, ohne notwendigerweise zur Server-Seite zu wechseln. Ihre Benutzeroberfläche kann einen eigenen Präsentator und ein eigenes Modell haben, das vollständig auf der Client-Seite lebt. Der Presenter steuert die Logik der UI-Interaktion/Validierung usw., während das Modell Zustandsinformationen speichert und ein Portal für das Backend bereitstellt (wo Sie ein separates Modell haben können).

Sie sollten sich auch die Moderator First TDD-Technik ansehen.

0
hinzugefügt

Was ich mache ist, den Dom anzustupsen, um zu sehen, ob ich bekomme, was ich erwarte. Ein großer Nebeneffekt ist, dass Sie Ihre App schnell machen, wenn Sie Ihre Tests schnell machen.

Ich habe gerade ein Open-Source-Toolkit veröffentlicht, das mit JavaScript-TDD immens helfen wird. Es ist eine Zusammensetzung von vielen Open-Source-Tools, die Ihnen eine funktionierende Requires Backbone-App von der Stange bietet.

Es bietet einzelne Befehle zum Ausführen: dev Web-Server, Jasmin einzelner Browser-Test-Runner, Jasmine js-Test-Treiber Multi-Browser-Test-Runner und Verkettung/Verkleinerung für JavaScript und CSS. Es gibt auch eine unminifizierte Version Ihrer App für das Debugging der Produktion aus, kompiliert Ihre Lenkervorlagen vor und unterstützt die Internationalisierung.

Keine Einrichtung ist erforderlich. Es funktioniert einfach.

http://github.com/davidjnelson/agilejs

0
hinzugefügt

Ich bin gerade dabei, Javascript TDD an einem neuen Projekt zu beginnen, an dem ich gerade arbeite. Mein derzeitiger Plan ist, qunit zu verwenden, um den Unit-Test zu machen. Während der Entwicklung können die Tests ausgeführt werden, indem einfach die Testseite in einem Browser aktualisiert wird.

Zur kontinuierlichen Integration (und um sicherzustellen, dass die Tests in allen Browsern ausgeführt werden), verwende ich Selenium , um den Test automatisch zu laden Kabelbaum in jedem Browser, und lesen Sie das Ergebnis. Diese Tests werden bei jedem Check-in zur Versionskontrolle ausgeführt.

Ich werde auch JSCoverage verwenden, um Code Coverage-Analysen der Tests zu erhalten. Dies wird auch mit Selen automatisiert.

Ich bin gerade dabei, das einzurichten. Ich werde diese Antwort mit genaueren Details aktualisieren, sobald ich das Setup ausgearbeitet habe.


Testwerkzeuge:

0
hinzugefügt

Dies ist der Hauptgrund, warum ich zum Google Web Toolkit gewechselt habe ... Ich entwickle und teste in Java und habe vernünftige Erwartungen, dass das kompilierte JavaScript in einer Vielzahl von Browsern richtig funktioniert. Da TDD in erster Linie eine Unit-Test-Funktion ist, kann der Großteil des Projekts vor der Kompilierung und Bereitstellung entwickelt und getestet werden.

Integration und funktionale Testsuites stellen sicher, dass der resultierende Code nach der Bereitstellung auf einem Testserver wie erwartet funktioniert.

0
hinzugefügt

Ich habe nie erfolgreich TDDed UI-Code. Am nächsten kamen wir, um den UI-Code so weit wie möglich von der Anwendungslogik zu trennen. Dies ist ein Grund, warum das Model-View-Controller-Muster nützlich ist - das Modell und der Controller können ohne viel Aufwand und ohne zu kompliziert zu werden TDDed werden.

Meiner Erfahrung nach war die Ansicht immer für unsere Benutzerakzeptanztests (wir schrieben Webanwendungen und unsere UATs verwendeten Java's HttpUnit). Auf dieser Ebene ist es jedoch wirklich ein Integrationstest, ohne die Test-in-Isolation-Eigenschaft, die wir mit TDD wünschen. Aufgrund dieser Konfiguration mussten wir zuerst unseren Controller/Modelltest/Code schreiben, dann die UI und die entsprechende UAT. Im GUI-Code von Swing, den ich in letzter Zeit geschrieben habe, habe ich den GUI-Code zuerst mit Stubs geschrieben, um mein Design des Frontends zu erkunden, bevor ich ihn zum Controller/Modell/API hinzufüge. YMMV hier aber.

Um das zu wiederholen, der einzige Rat, den ich geben kann, ist das, was Sie bereits vermuten - trennen Sie Ihren UI-Code so weit wie möglich von Ihrer Logik und tendieren Sie sie.

0
hinzugefügt

Ich habe in der Vergangenheit einige TDD mit Javascript gemacht, und was ich tun musste, war die Unterscheidung zwischen Unit- und Integrationstests. Selenium testet Ihre gesamte Website mit der Ausgabe vom Server, seinen Postbacks, Ajax-Calls, all dem. Aber für Unit-Tests ist nichts davon wichtig.

Was Sie wollen, ist nur die Benutzeroberfläche, mit der Sie interagieren werden, und Ihr Skript. Das Werkzeug, das Sie dafür verwenden, ist JsUnit , das ein HTML-Dokument mit einigen Javascript-Funktionen verwendet auf der Seite und führt sie im Kontext der Seite aus. Also, was Sie tun werden, ist die Stubbed-HTML auf der Seite mit Ihren Funktionen. Von dort aus können Sie die Interaktion Ihres Skripts mit den UI-Komponenten in der isolierten Einheit des gespiegelten HTML, Ihrem Skript und Ihren Tests testen.

Das mag ein wenig verwirrend sein, also sehen wir, ob wir einen kleinen Test machen können. Lässt einige TDD annehmen, dass nach dem Laden einer Komponente eine Liste von Elementen basierend auf dem Inhalt der LI gefärbt wird.

tests.html

<html>
<head>
<script src="jsunit.js"></script>
<script src="mootools.js"></script>
<script src="yourcontrol.js"></script>
</head>
<body>
    
  • red
  • green
   
</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, weshalb wir für unsere Kontrolle mehrere Beispiele benötigen.

yourcontrol.js (Schritt1)

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 den Schmerzpunkt hier wahrscheinlich sehen, Sie müssen Ihren gespielten HTML-Code hier auf der Seite synchron mit der Struktur dessen, was Ihr Server steuert, behalten. Aber es bringt Ihnen ein schönes System für TDD mit JavaScript.

0
hinzugefügt