Nachdem Sie Stunden verbracht haben, k?nnen Sie eine fantastische neue Funktion für Ihre Webanwendung endgültig in Aktion sehen. Sie fügen den neuen Code zu Ihrer JavaScript -Basis hinzu, erstellen den Release -Kandidaten und starten Ihren Browser, um erstaunt zu sein. Dann… ?hm, oh… die neue Funktion mag einwandfrei funktionieren, aber ein anderer kritischer Teil Ihrer App - ein Teil, den Sie bei der Entwicklung der neuen Version nicht berührt haben - ist schrecklich schief geworden. Jetzt sind Sie vor der Herausforderung, durch Arbeitstage zu versuchen, herauszufinden, wie Sie den vorhandenen Code gebrochen haben. Happy Days sind definitiv nicht wieder da. Dieses Szenario hat mich mehr gebissen, als ich zugeben m?chte. Und wenn Sie eine Weile codiert haben, haben Sie es wahrscheinlich auch gesehen. Bedenken Sie jedoch, was dieses Szenario so schmerzhaft macht. Es liegt nicht wirklich daran, dass unser neuer Code den vorhandenen Code gebrochen hat. Das ist unvermeidlich in der Entwicklung. Der wahre Schmerz ist, dass es so lange dauerte, um den Bruch zu bemerken. Bei so viel Entwicklung, da wir wussten, dass unsere Anwendung funktioniert, gibt es eine gro?e Menge an Code, in dem sich der Fehler versteckt. Und obwohl es ein bisschen wie die Jagd nach einer Nadel in einem Heuhaufen erscheinen mag, haben wir keine andere Wahl, als sie zu tauchen.

In diesem Artikel werden wir dieses Szenario aus unserer JavaScript -Entwicklung wirklich verbannen. Kein Durchsuchen von Stunden, Tagen oder Wochen Code, die nach einer Nadel suchen. Das Prinzip, das wir übernehmen werden, ist einfach: Finden Sie einen Fehler

, sobald wir

es erstellen. Das ist richtig. Wir werden eine Entwicklungsumgebung und einen Prozess einrichten, der uns sofort mitteilt, wenn wir Code schreiben, der einen Fehler einführt. Darüber hinaus wird die zus?tzliche Anstrengung, die wir in den Prozess unternommen haben, nicht nach Abschluss der Erstentwicklung nicht mehr verschwendet. Der gleiche Testcode, der unsere Entwicklungsfehler f?ngt, ist in einer Integrationsumgebung vollst?ndig wiederverwendbar. Wir k?nnen die Tests problemlos in unser Quellcode -Managementsystem einbeziehen und Fehler blockieren, bevor sie überhaupt in unsere Codebasis einsteigen k?nnen.

In den folgenden vier Abschnitten werden wir uns zun?chst die Tools ansehen, die wir für eine JavaScript -Testumgebung ben?tigen. Wir werden dann eine triviale Anwendung in Betracht ziehen, die einfach genug ist, um sie zu verstehen, aber über alle Funktionen und Funktionen verfügt, die in einer realen Webanwendung vorhanden sind. Die letzten beiden Abschnitte zeigen, wie wir unsere Umgebung nutzen k?nnen, um die Beispiel -App w?hrend der Entwicklung zu testen, und nach Abschluss der ersten Entwicklung w?hrend der Integration.

Key Takeaways

• betonen die frühzeitige Erkennung von Fehler w?hrend der Entwicklung, um komplexe Probleme in sp?teren Phasen zu verhindern, ein reibungsloses Codierungserlebnis zu gew?hrleisten und die Rückverfolgung zu minimieren.
• Verwenden Sie Mokka aufgrund seiner Kompatibilit?t sowohl mit Browser- als auch mit Node.js -Umgebungen als Kerntest -Framework, wodurch der nahtlose übergang von der Entwicklung zu Integrationstests erm?glicht wird.
• Integrieren Sie die Chai -Assertion -Bibliothek, um die Lesbarkeit und Flexibilit?t der Tests zu verbessern und mehrere Stile anzubieten (zu erwarten), die unterschiedliche Entwicklerpr?ferenzen aussprechen.
• Sinon.js zum Erstellen von Spione, Stubs und Mocks besch?ftigen, die für das Testen von Interaktionen mit externen Bibliotheken und Diensten unerl?sslich sind, ohne ihre Operationen zu beeinflussen.
• Richten Sie eine kontinuierliche Testumgebung mit Test'EM ein, um Tests bei Code?nderungen automatisch auszuführen und so ein sofortiges Feedback zur Gesundheit der Anwendung zu erhalten.
• W?hrend der Entwicklung konzentrieren Sie sich auf die Erstellung detaillierter Unit -Tests für Modelle, Ansichten und Sammlungen, um sicherzustellen, dass jede Komponente isoliert korrekt funktioniert.
• übergang reibungslos zu Integrationstests, indem die Einheitstests für die Befehlszeilenausführung mit node.js angepasst werden, um sicherzustellen, dass sich die Anwendung wie erwartet in der Produktionsumgebung verh?lt.

Zusammenstellung einer JavaScript -Testumgebung

Unsere Einheitstests Nirvana erfordert einige Entwicklungstools, die (noch) nicht in Ihrer Workbench enthalten sind. Die Nachrichten, sowohl gut als auch schlecht, ist, dass es viele Optionen gibt. Das sind gute Nachrichten, weil es uns Optionen gibt, und das sind schlechte Nachrichten, denn das Tempo der heutigen Entwicklung von Front End bedeutet, dass es viel zu viele Optionen gibt. Um unsere Bewertung zu fokussieren, lassen Sie uns explizit über unsere beiden besten Ziele gehen. Alles andere ist sekund?r:

1. Unsere Umwelt muss reibungslose, kontinuierliche Tests w?hrend der Entwicklung unterstützen.
2. w?hrend der Entwicklung erstellte Tests müssen in der Integration gleicherma?en verwendbar sein.

Ausführungsumgebungen

Für die JavaScript -Codierung gibt es keine bessere Entwicklungsumgebung als der moderne Webbrowser. Unabh?ngig davon, ob Ihr Geschmack Firebug oder Webkit's Developer Tools ist, unterstützt der Browser die Live -DOM -Inspektion und -bearbeitung, das vollst?ndige interaktive Debugging und die hoch entwickelte Leistungsanalyse. Webbrowser eignen sich hervorragend für die Entwicklung. Daher müssen sich unsere Testwerkzeuge und unsere Umgebung in die Entwicklung des Browsers integrieren. Webbrowser sind jedoch nicht so gut für Integrationstests. Integrationstests werden h?ufig irgendwo in der Cloud (oder am wenigsten irgendwo im Rechenzentrum) auf Servern stattfinden. Diese Systeme haben nicht einmal eine grafische Benutzeroberfl?che, geschweige denn ein moderner Webbrowser. Für effiziente Integrationstests ben?tigen wir einfache Befehlszeilenskripte und eine JavaScript -Ausführungsumgebung, die sie unterstützt. Für diese Anforderungen ist das Tool der Wahl Node.js. Obwohl es eine andere Befehlszeile für JavaScript -Umgebungen gibt, hat keiner die Breite und Tiefe der Unterstützung, um Node.js. In der Integrationsphase müssen sich unsere Testwerkzeuge in node.js.

integrieren

Test Framework

Jetzt, da wir festgestellt haben, dass unsere Test -Tools sowohl Webbrowser- als auch Node.js -Umgebungen unterstützen müssen, k?nnen wir die Auswahlm?glichkeiten eingrenzen, um ein Kern -Test -Framework auszuw?hlen. Es gibt viele JavaScript -Test -Frameworks, aber die meisten sind stark auf Browser -Tests voreingenommen. Es ist normalerweise m?glich, sie mit node.js zum Arbeiten zu bringen, erfordert jedoch oft unelegante Hacks oder ?nderungen. Ein Rahmen, der nicht unter diesem Problem leidet, ist Mokka, das sich zu Recht als:

beschreibt

Mokka ist ein featurereiches JavaScript-Test-Framework, das auf Knoten und Browser ausgeführt wird, wodurch asynchrone Tests einfach und unterhaltsam sind.

Ursprünglich für Node.js entwickelt, wurde Mokka erweitert, um auch Webbrowser zu unterstützen. Durch die Verwendung von Mocha als Testframework k?nnen wir Tests schreiben, die sowohl die Entwicklung als auch die Integration ohne ?nderung unterstützen.

Assertion Library

Im Gegensatz zu einigen JavaScript -Test -Frameworks wurde Mokka für maximale Flexibilit?t ausgelegt. Infolgedessen müssen wir ein paar zus?tzliche Teile ausw?hlen, um es vollst?ndig zu machen. Insbesondere brauchen wir eine JavaScript -Assertion -Bibliothek. Dafür verlassen wir uns auf die Chai Assertion Library. Chai ist insofern etwas einzigartig, als es alle g?ngigen Assertionsstile unterstützt - Assert , erwarten, und sollten. Code. Unter den Abdeckungen sind sie alle gleichwertig. Es ist einfach, Tests von einem Behauptungsstil zum anderen zu übersetzen. Der Hauptunterschied in den Behauptungsstilen ist ihre Lesbarkeit. Die Auswahl des Behauptungsstils h?ngt haupts?chlich davon ab, welchen Stil Sie (oder Ihr Team) am lesbarsten finden und welcher Stil die verst?ndlichsten Tests erzeugt. Um den Unterschied zu erkennen, sollten Sie einen trivialen Test für den folgenden Code entwickeln:

<span>var sum = 2 + 2;</span>

Ein traditioneller Test im Assert-Stil k?nnte geschrieben werden als:

assert<span>.equal(sum, 4, "sum should equal 4");</span>

Dieser Test erledigt die Aufgabe, aber wenn Sie sich jedoch nicht an die Tests der alten Schule gew?hnt haben, ist es wahrscheinlich ein wenig schwierig, zu lesen und zu interpretieren. Ein alternativer Behauptungsstil verwendet Erwartung:

<span>expect(sum).to.equal(4);</span>

Die meisten Entwickler finden, dass Behauptungen im Stil von Erwartung leichter zu lesen und zu verstehen sind als Tests im Assert-Stil. Die dritte Alternative sollte Testbehauptungen noch mehr wie natürliche Sprache:

sum<span>.should.equal(4);</span>

Die Chai -Bibliothek unterstützt alle drei Assertionsstile. In diesem Artikel bleiben wir sollten.

Spione, Stubs und Mocks

Die meisten Web -Apps, einschlie?lich des trivialen Beispiels, das wir in diesem Artikel berücksichtigen, stützen sich auf Bibliotheken und Dienste von Drittanbietern. In vielen F?llen erfordert das Testen unseres Codes diese Bibliotheken und Dienste beobachten oder sogar kontrollieren -. Die Sinon.js -Bibliothek bietet viele Tools zum Testen dieser Interaktionen. Solche Werkzeuge fallen in drei allgemeine Klassen:

• Spion . Testcode, der Aufrufe zu Funktionen au?erhalb des zu testenden Code beobachtet. Spione beeintr?chtigen den Betrieb dieser externen Funktionen nicht; Sie zeichnen lediglich den Aufruf und den Rückgabewert auf.
• Stub . Testcode, der für Aufrufe von Funktionen au?erhalb des zu testenden Codes steht. Der Stub -Code versucht nicht, die externe Funktion zu replizieren. Es verhindert einfach ungel?ste Fehler, wenn der untersuchte Code auf die externe Funktion zugreift.
• Mock . Testen Sie den Code, der Funktionen oder Dienste au?erhalb des untersuchten Codes nachahmt. Mit Mocks kann der Testcode die Rückgabewerte aus diesen Funktionen oder Diensten angeben, damit er die Antwort des Codes überprüfen kann.

Zusammen mit der Sinon.js -Bibliothek selbst k?nnen wir die Standard -Chai -Assertion -Bibliothek mit Sinon.js -Behauptungen für Chai erh?hen.

Eine Umgebung für die Entwicklung von Unit -Tests

Das letzte Werkzeug für unsere Test -Workbench ist eine Entwicklungsumgebung für Unit -Tests. In unserem Beispiel werden wir Test'EM verwenden. Test'EM ist eine Sammlung praktischer Skripte, um eine kontinuierliche Testumgebung einzurichten und auszuführen. Wir k?nnten, wenn wir uns dafür entscheiden, die Skripte selbst schreiben und die Umgebung manuell verwalten. Toby Ho (Test’em's Creator) hat jedoch ein fantastisches Paket zusammengestellt, das uns die Mühe sparen kann.

Die Beispielanwendung

Um unsere Testumgebung in Aktion zu sehen, betrachten wir eine einfache Anwendung. Obwohl diese Anwendung mit seinen n?tigen Wesentlichen entspricht, enth?lt sie alle Funktionen für eine reale Anwendung. (Der vollst?ndige Quellcode für die Anwendung ist auf GitHub verfügbar.)

Benutzer k?nnen ihre Liste der Todos sehen und sie k?nnen auf ein Kontrollk?stchen klicken, um den Status eines jeden Todo zu umschalten.

Die Todos -Datenbank

Unsere Anwendung beginnt mit einer Datenbanktabelle, in der die Informationen für TODOS enthalten sind. Hier ist der SQL, mit dem wir diese Tabelle erstellen k?nnen.

<span>var sum = 2 + 2;</span>

Und so ist die Tabelle, für die wir einige Testdaten einfügen k?nnten.

id Titel vollst?ndig 1a Beispiel für Todoelement in der Datenbank0 2another Probe TODO Item1 3yet ein weiteres Beispiel todo item00

Wie die Tabelle zeigt, enthalten unsere Todos nur einen Prim?rschlüssel (ID), einen Titel und ein Statusbit, um anzuzeigen, ob sie vollst?ndig sind oder nicht.

Eine REST -API

Unsere Webanwendung ben?tigt Zugriff auf diese Datenbank, sodass wir eine Standard -REST -Schnittstelle bereitstellen. Die API folgt den Ruby Conventions, kann jedoch einfach von jeder Servertechnologie implementiert werden. Insbesondere:

• GET API/TODOS gibt ein JSON-kodierter Array aller Zeilen in der Datenbank zurück.
• GET API/TODOS/NNN RETTIERT Die JSON -Darstellung des TODO mit ID gleich nnn.
• post api/todos fügt der Datenbank mit den JSON-kodierten Informationen in der Anfrage ein neues Todo hinzu.
• API/TODOS/NNN-Aktualisierung der TODO mit der ID gleich NNN mit den JSON-kodierten Informationen in der Anfrage aktualisiert.
.
api/todos/nnn l?schen l?scht die Todo mit ID, die nnn aus der Datenbank entspricht.

Wenn Sie Ruby nicht besonders m?gen, enth?lt der Quellcode eine vollst?ndige PHP -Implementierung dieser API.

JavaScript -Bibliotheken

Unsere bescheidene Anwendung ist einfach genug, um in reinem JavaScript ohne Bibliotheken zu implementieren, aber wir haben weitaus gr??ere Pl?ne. Wir starten vielleicht klein, aber schlie?lich wird die App erstaunliche Funktionen und eine entzückende Benutzeroberfl?che bieten. In Vorbereitung auf diesen Tag werden wir auf einem Framework aufbauen, das unsere Ultimate Killer -App unterstützen kann:

• jQuery für DOM -Manipulation, Ereignisbehandlung und Serverkommunikation.
• unterstrich.js, um die Kernsprache mit vielen unbest?ndigen Versorgungsunternehmen zu verbessern.
• Backbone.js, um die Struktur der Anwendung in Bezug auf Modelle und Ansichten zu definieren.

ein HTML -Skelett

Jetzt, da wir die Komponenten kennen, die unsere Anwendung umfassen, k?nnen wir das HTML -Skelett definieren, das es unterstützt. Es ist (noch) nichts Besonderes, nur ein minimales HTML5 -Dokument, einige JavaScript -Dateien und ein kleines Stück Code, um die Dinge zu beginnen.

<span>var sum = 2 + 2;</span>

Tests w?hrend der Entwicklung

Nachdem wir unsere Tools ausgew?hlt und die Anwendung angegeben haben, ist es an der Zeit, die Entwicklung zu beginnen. Unsere erste Aufgabe ist die Installation der Tools.

installieren Sie die Tools

Obwohl wir uns im Browser entwickeln werden, beruht unsere Testumgebung auf node.js. Der allererste Schritt ist daher die Installation von Node.js und dem Node Package Manager (NPM). Auf der Website node.js gibt es ausführbare Bin?rdateien für OS X, Windows, Linux und Sunos sowie einen Quellcode für andere Betriebssysteme. Nach dem Ausführen des Installationsprogramms k?nnen Sie sowohl node.js als auch npm über die Befehlszeile überprüfen.

assert<span>.equal(sum, 4, "sum should equal 4");</span>

Alles andere, was wir brauchen, ist bequem als Knotenpaket erh?ltlich. Der Knotenpaket -Manager kann seine Installation sowie alle Abh?ngigkeiten verarbeiten.

<span>expect(sum).to.equal(4);</span>

Erstellen der Projektstruktur

Der Quellcode für dieses Beispiel enth?lt eine vollst?ndige Projektstruktur mit den folgenden 15 Dateien:

sum<span>.should.equal(4);</span>

Hier ist, was jeder Ordner und die Datei enth?lt:

• Todos.html: Die Skelett -HTML -Datei für unsere Anwendung, vollst?ndig oben angezeigt.
• testem.json: Die Konfigurationsdatei für Test'EM; Wir werden uns das in Kürze ausführlich ansehen.
• API/: Ein Ordner für unsere REST -API -Implementierung.
  • api/htaccess: Beispielkonfiguration für den Apache -Webserver, der unsere REST -API unterstützt.
  • api/todos.php: PHP -Code zur Implementierung der REST -API.
• lib/: Ein Ordner für JavaScript -Bibliotheken, die von der App selbst und dem Test -Framework verwendet werden.
  • lib/backbone-min.js: Minified Version von Backbone.js.
  • lib/chai.js: Chai Assertion Library.
  • lib/jQuery-1.9.0.min.js: Minified Version von JQuery.
  • lib/sinon-1.5.2.js: Sinon.js Library.
  • lib/sinon-chai.js: Sinon.js Behauptungen für Chai.
  • lib/unterstrich-min.js: Minified Version von UnsCore.js.
• Mysql/: Ein Ordner für MySQL -Code für die Anwendung.
  • mysql/todos.sql: MySQL -Befehle zum Erstellen der Anwendungsdatenbank.
• PHP-LIB/: Ein Ordner für PHP-Bibliotheken und Konfiguration für die REST-API der Anwendung.
  • php-lib/dbconfig.inc.php: PHP-Datenbankkonfiguration für die Rest-API.
• src/: Ein Ordner für unseren clientseitigen Anwendungscode.
  • src/App-todos.js: Unsere Anwendung.
• Test/: Ein Ordner für den Testcode.
  • test/App-todos-test.js: Testcode für unsere Anwendung.
  • test/mocha.opts: Konfigurationsoptionen für Mokka; Wir werden uns das im n?chsten Abschnitt ansehen.

W?hrend der Entwicklung interessieren wir uns nur für drei dieser Dateien, testem.json, src/App-todos.js und test/App-todos-test.js.

test’em

konfigurieren

Der letzte Schritt vor der tats?chlichen Entwicklung ist die Definition der Test'EM -Konfiguration. Diese Konfiguration befindet sich im JSON-formatierten Testem.json und ist einfach genug, um in jedem Texteditor zu erstellen. Wir geben lediglich an, dass wir Mokka verwenden (test’em unterstützt mehrere Frameworks) und listen die JavaScript -Dateien auf, die unsere Anwendung und unser Testcode ben?tigt.

<span>var sum = 2 + 2;</span>

Beginnen Sie mit der Entwicklung

Schlie?lich k?nnen wir codieren. Navigieren Sie in einer Befehlsschale zum Stammordner unseres Projekts und führen Sie das Befehlstestem aus. In den Tests -Skripten wird das Terminalfenster gel?scht und uns eine URL oben rechts geben. Kopieren Sie diese URL in unseren Browser Ihrer Wahl und wir sind ausgeschaltet.

Sobald wir den Webbrowser starten, werden automatisch alle von uns definierten Tests ausgeführt. Da wir gerade erst mit der Entwicklung beginnen, haben wir keinen Code oder keine Testf?lle. Der Browser wird uns freundlich darauf hinweisen.

Das Terminalfenster, aus dem wir Test'EM gestartet haben, gibt uns auch den Status.

Ein erster Testfall

Im Geiste der echten testgetriebenen Entwicklung werden wir mit unserem ersten Testfall in der Datei test/App-todos-test.js schreiben. Wie bei jeder guten Web -App m?chten wir die Verschmutzung des globalen Namensraums minimieren. Dazu verlassen wir uns auf eine einzelne globale Variable, Todoapp, um unseren gesamten Code zu enthalten. In unserem ersten Testfall wird sichergestellt

<span>var sum = 2 + 2;</span>

Wie Sie sehen, brauchen wir eine vorl?ufige Erkl?rung, um Mokka mitzuteilen, dass wir Chai -Behauptungen verwenden. Dann k?nnen wir beginnen, Tests zu schreiben. Durch Konvention werden JavaScript-Tests in Bl?cke organisiert (die in Unterblockierungen usw. verschachtelt werden k?nnen). Jeder Block beginnt mit einem Funktionsaufruf von beschreiben (), um zu ermitteln, welchen Teil des Code, den wir testen. In diesem Fall testen wir die Gesamtanwendung. Dies ist also der erste Parameter, der beschreibt ().

In einem Testblock dokumentieren wir jeden Testfall nach dem, was es testet. Das ist der Zweck der IT () -Funktion. Der Weg zum Lesen eines Testfalls besteht darin, die Beschreibung () und IT () in eine einzelne Aussage zu kombinieren. Unser erster Testfall ist daher

Anwendung erstellt eine globale Variable für den Namensraum

Der Testcode selbst befindet sich im IT () -Block. Unser Testfall ist

assert<span>.equal(sum, 4, "sum should equal 4");</span>

Jetzt haben wir einen vollst?ndigen Testfall. Sobald wir die Datei speichern, übernimmt Test`em automatisch. Es wird festgestellt, dass sich eine unserer Dateien ge?ndert hat, sodass sie die Tests sofort erneut ausführt. Es ist nicht überraschend (da wir noch keinen Code für die Anwendung geschrieben haben) unser erster Test schl?gt fehl.

Das Terminalfenster aktualisiert auch automatisch.

Um den Testpass zu erstellen, müssen wir die globale Variable der Namensraum erstellen. Wir wechseln zur Datei srcapp-todos.js und fügen den erforderlichen Code hinzu.

<span>expect(sum).to.equal(4);</span>

Sobald wir die Datei speichern, tritt Test`em erneut in Aktion. Wir erhalten sofort aktualisierte Ergebnisse für unsere Testf?lle.

Treten Sie für einen Moment zurück und überlegen Sie, was passiert! Jedes Mal, wenn wir eine ?nderung des Testcode oder in unserer Anwendung vornehmen, werden Tests unsere gesamte Testsuite sofort erneut ausführen. Alles, was wir tun müssen, ist, den Browser- oder Terminalfenster von Test’em in einer Ecke unseres Bildschirms sichtbar zu halten, und wir k?nnen die Gesundheit unseres Code in Echtzeit sehen,

, w?hrend wir entwickeln. Wir werden wissen, sobald wir einen Fehler einführen, auch wenn sich der Fehler in einem Teil des Codes manifestiert, der sich von dem Ort unterscheidet, in dem wir arbeiten. Kein Durchgabestand durch Stunden, Tage oder Wochen neuer Code, um herauszufinden, wann wir einen Fehler eingeführt haben.

Testen Sie das Modell

Mit unserer jetzt vollst?ndig etablierten Entwicklungsumgebung k?nnen wir mit der Entwicklung der Anwendung beginnen. Da unsere App eine Liste von Todos zeigt, ist es m?glicherweise gut, ein Modell für diese Todos zu erstellen. Das Modell muss sowohl den Titel des Todo als auch des Status im Auge behalten. Fügen wir einen Unit -Test hinzu, der überprüft, dass wir ein Todo mit angemessenen Standardeinstellungen erstellen k?nnen.

<span>var sum = 2 + 2;</span>

Es sind mehrere Aspekte dieser Tests erw?hnenswert.

• Wir k?nnen Testbl?cke ineinander nisten. Ein Testblock enth?lt alle Unit-Tests für das TODO-Modell, und ein Unterblock dieser Tests konzentriert sich auf die Initialisierung.
• In einem Testblock k?nnen wir die Funktionalit?t vor jedem Test definieren. Das ist der Zweck des Blocks vorab (). Im obigen Beispiel erstellen wir vor jedem Test eine neue Instanz eines TODO.
• Das Mocha -Framework stellt automatisch sicher, dass der JavaScript -Kontext (d. H. Der Wert dieser) für alle unsere Testf?lle konsistent ist. Aus diesem Grund k?nnen wir dies in einer Funktion (der Parameter vorab () () definieren und sicher in anderen Funktionen (z. B. die IT () -Parameter) verweisen. Ohne Mokka, die hinter den Kulissen arbeitet, um diese Konsistenz bereitzustellen, würde JavaScript verschiedene Kontexte für jede Funktion definieren.

, da wir den Modellcode noch nicht geschrieben haben, werden alle unsere Tests fehlschlagen. (Und das werden wir sofort wissen.) Aber sobald wir den Code für unser Modell hinzugefügt haben, bestehen die Tests und wir sind auf dem Weg.

assert<span>.equal(sum, 4, "sum should equal 4");</span>

Verwenden von Stubs für die Funktionalit?t von Drittanbietern

Jetzt, da wir ein einfaches Modell für Todos haben, k?nnen wir beginnen, sein Verhalten zu definieren. Eine Sache, die unser Modell tun sollte, ist die Datenbank zu aktualisieren, wenn sich eine der Eigenschaften ?ndert. In einer Unit -Testumgebung haben wir jedoch keine tats?chliche Datenbank zu überprüfen. Andererseits schreiben wir keinen Code, um das Datenbankaktualisierung durchzuführen. Vielmehr verlassen wir uns auf das Rückgrat, um diese Interaktion zu bew?ltigen. Dies deutet auf eine Unit -Teststrategie für diesen Testfall hin. Alles, was wir wissen müssen, ist, dass Backbone -Modelle die Save () -Methode verwenden, um den Backing -Store zu aktualisieren, der das Modell anh?lt. In unserem Fall ist dieser Backing -Store die Datenbank. Hier ist der Unit -Testcode, den wir verwenden k?nnen:

<span>expect(sum).to.equal(4);</span>

Wir haben vor jedem Test einen zus?tzlichen Code beigefügt und nach jedem Test einen Codeabschnitt hinzugefügt. Dieser zus?tzliche Code verwaltet einen Sinon -Stub, eine Funktion, die eine andere Funktion im Code effektiv aufgibt. In unserem Fall nimmt der Stub die Save () -Methode dieser. Mit dem Stub gehen Anrufe der Methode nicht in die Backnone -Bibliothek. Stattdessen f?ngt Sinon diese Anrufe ab und kehrt einfach sofort zurück. Dieses Verhalten ist wichtig. Wenn wir versuchen, die tats?chliche Backbone Save () -Methode in einer Unit -Testumgebung auszuführen, würde der Anruf fehlschlagen, da keine Datenbank oder Server -API verfügbar w?re.

Mit dem Stub k?nnen unsere Testf?lle das Verhalten des Modells überprüfen. Im ersten Testfall setzen wir den Titel des Todo sofort auf einen neuen Wert. Da dies die Titeleigenschaft ?ndert, m?chten wir, dass unser Modell seinen Backing -Store aktualisiert. Um zu überprüfen, ob wir einfach überprüfen, ob der Stub aufgerufen wurde. Damit unser Modell diese Tests bestanden hat, k?nnen wir nach ?nderungsereignissen suchen und angemessen reagieren.

<span>var sum = 2 + 2;</span>

Testen Sie die Ansicht

Natürlich wird unsere App niemandem gut tun, wenn sie den Benutzern die Todos nicht tats?chlich anzeigt, und dies erfordert das Erstellen von HTML. Wir werden Backbone -Ansichten für diese Funktionalit?t verwenden. In unserer trivialen App m?chten wir einfach jeden Todo als Listenelement rendern. Hier sind die Testf?lle, die uns anfangen.

assert<span>.equal(sum, 4, "sum should equal 4");</span>

Wir beginnen unsere Tests der Ansicht mit zwei Testf?llen. Zuerst stellen wir sicher, dass die Render () -Methode der Ansicht die Ansicht selbst zurückgibt. Dies ist eine übliche und sehr bequeme Konvention im Rückgrat, da sie die Methodenverkettung erm?glicht. Unser zweiter Testfall überprüft, dass das HTML -Element, das das Render erstellt, ein Listenelement ist (

). Der Code, der für diese Tests erforderlich ist, ist eine einfache Rückgratansicht.

<span>expect(sum).to.equal(4);</span>

Als n?chstes k?nnen wir den detaillierten Inhalt dieser Listenelementansicht entwickeln. Als Beispiel m?chten wir, dass das vollst?ndige Listenelement ungef?hr wie folgt aussieht.

sum<span>.should.equal(4);</span>

Für unsere Testf?lle k?nnen wir JQuery nutzen, um einzelne Elemente aus dem Hauptelement der Ansicht zu extrahieren.

CREATE TABLE `todos` (
  `id`       int(11)      NOT NULL AUTO_INCREMENT COMMENT 'Primary key for the table.',
  `title`    varchar(256) NOT NULL DEFAULT ''     COMMENT 'The text for the todo item.',
  `complete` bit(1)       NOT NULL DEFAULT b'0'   COMMENT 'Boolean indicating whether or not the item is complete.',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='To Do items.'

Beachten Sie, dass wir im letzten Testfall die Methode des Modells Save () gestoppt haben. Da wir eine Eigenschaft von ihrem Standardwert ?ndern, wird unser Modell pflichtbewusst versuchen, diese ?nderung in seinem Backing -Shop zu bestehen. In einer Unit -Testumgebung verfügen wir jedoch nicht über eine Datenbank oder eine Server -API. Der Stub tritt an die Stelle der fehlenden Komponenten und erm?glicht die Tests ohne Fehler. Um diese Tests zu bestehen, müssen wir unserer Ansicht einen zus?tzlichen Code hinzufügen.

<span><span><!DOCTYPE html></span>
</span><span><span><span><html</span> lang<span>="en"</span>></span>
</span>  <span><span><span><head</span>></span>
</span>    <span><span><span><meta</span> charset<span>="utf-8"</span>></span>
</span>    <span><span><span><title</span>></span><span><span></title</span>></span>
</span>  <span><span><span></head</span>></span>
</span>  <span><span><span><body</span>></span>
</span>    <span><span><span><h1</span>></span>List of Todos<span><span></h1</span>></span>
</span>
    <span><span><span><script</span> src<span>="lib/jquery-1.9.0.min.js"</span>></span><span><span></script</span>></span>
</span>    <span><span><span><script</span> src<span>="lib/underscore-min.js"</span>></span><span><span></script</span>></span>
</span>    <span><span><span><script</span> src<span>="lib/backbone-min.js"</span>></span><span><span></script</span>></span>
</span>    <span><span><span><script</span> src<span>="src/app-todos.js"</span>></span><span><span></script</span>></span>
</span>    <span><span><span><script</span>></span><span>
</span></span><span><span>      <span>$(function () {
</span></span></span><span><span>        <span>var todos = new todoApp<span>.Todos</span>();
</span></span></span><span><span>        todos<span>.fetch();
</span></span></span><span><span>        <span>var list = new todoApp<span>.TodosList</span>({collection: todos});
</span></span></span><span><span>        <span>$("body").append(list.el);
</span></span></span><span><span>      <span>})
</span></span></span><span><span>    </span><span><span></script</span>></span>
</span>  <span><span><span></body</span>></span>
</span><span><span><span></html</span>></span></span>

Testmodell/Ansichtsinteraktionen

Jetzt, da wir überprüft haben, dass unsere Ansichtsimplementierung das richtige HTML -Markup erstellt, k?nnen wir seine Interaktion mit unserem Modell testen. Insbesondere m?chten wir sicherstellen, dass Benutzer einen Todo -Status umschalten k?nnen, indem wir auf das Kontrollk?stchen klicken. Unsere Testumgebung erfordert keinen tats?chlichen menschlichen Benutzer, daher werden wir JQuery verwenden, um das Click -Ereignis zu generieren. Dazu müssen wir jedoch einem echten Live -Dom Inhalte hinzufügen. Dieser Inhalt wird als Test Fixture bezeichnet. Hier ist der Unit -Testcode.

bash-3.2$ node --version
v0.8.18
bash-3.2$ npm --version
1.2.2
bash-3.2$

Beachten Sie, dass wir die Save () -Methode des Todo erneut stürzen. Andernfalls versucht Backbone, einen nicht existierenden Backing-Store zu aktualisieren, wenn wir den Todo-Status mit unserem simulierten Klick ?ndern.

Für den Testfall selbst erstellen wir zun?chst ein

-Element mit einer ID der Fixture und fügen dieses Element unserem Live -Dokument hinzu. Das Live -Dokument ist in diesem Fall die Webseite, auf der die Ergebnisse unserer Tests angezeigt werden. Obwohl wir das Element unmittelbar nach der überprüfung des Testfalles entfernen, setzen wir seine Anzeigeeigenschaft auch auf keine, sodass es die Anzeige der Testergebnisse durch Mokka nicht beeintr?chtigt. Der Code, der diese Funktionalit?t implementiert, enth?lt eine kleine Erg?nzung zum Todo -Modell. Der Zugabe ist eine neue Togglestatus () -Methode.

<span>var sum = 2 + 2;</span>

In der Ansicht m?chten wir Klickereignisse im Element aufnehmen und diese Methode für das Modell aufrufen.

assert<span>.equal(sum, 4, "sum should equal 4");</span>

Testen Sie die Sammlung

Zu diesem Zeitpunkt ist unsere Bewerbung nahezu vollst?ndig. Die einzige verbleibende Funktionalit?t besteht darin, alle Todos zusammen zu sammeln. Natürlich verwenden wir eine Backbone -Sammlung. Wir werden mit unserer Sammlung eigentlich nichts Besonderes machen, daher brauchen wir keine Unit -Tests.

<span>expect(sum).to.equal(4);</span>

Wir k?nnen jedoch überprüfen, ob unsere Implementierung der Ansicht der Sammlung angemessen ist. Wir m?chten, dass diese Ansicht als ungeordnete Liste (

) gemacht wird. Die Testf?lle erfordern keine Funktionen, die wir zuvor noch nicht gesehen haben.

sum<span>.should.equal(4);</span>

Die Implementierung der Ansicht ist ebenfalls unkompliziert. Es verfolgt alle Erg?nzungen zur Sammlung und aktualisiert die Ansicht. Für das erste Render () fügt es einfach alle Modelle in der Sammlung einzeln hinzu.

CREATE TABLE `todos` (
  `id`       int(11)      NOT NULL AUTO_INCREMENT COMMENT 'Primary key for the table.',
  `title`    varchar(256) NOT NULL DEFAULT ''     COMMENT 'The text for the todo item.',
  `complete` bit(1)       NOT NULL DEFAULT b'0'   COMMENT 'Boolean indicating whether or not the item is complete.',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='To Do items.'

Bonustests: überprüfen Sie die API

Da unsere REST -API perfekt der API übereinstimmt, die das Rückgrat erwartet, ben?tigten wir keinen benutzerdefinierten Code, um die API -Interaktion zu verwalten. Infolgedessen ben?tigen wir keine Unit -Testf?lle. In der realen Welt haben Sie vielleicht nicht so viel Glück. Wenn Ihre API nicht den Rückgratkonventionen entspricht, müssen Sie m?glicherweise einen Teil des Backbone-Code überschreiben oder erweitern, um mit der nicht standardm??igen API umzugehen. Dieser zus?tzliche Code ben?tigt auch Unit -Tests. Glücklicherweise ist es relativ einfach, API -Wechselwirkungen zu testen, selbst in einer Unit -Testumgebung.

Der einfachste Weg, die API -Interaktionen zu testen, basiert auf der gef?lschten Serverfunktionalit?t von Sinon.js. Leider ist diese Funktionalit?t nur (derzeit) in der Browser -Implementierung von Sinon verfügbar. Es wird ausdrücklich von der Implementierung von Node.js ausgeschlossen. Es gibt einige Hacks, die es in Node.js zum Laufen bringen, aber diese Hacks sind ziemlich spr?de und verlassen sich auf interne Implementierungsdetails. Es w?re am besten, sie nach M?glichkeit zu vermeiden. Glücklicherweise k?nnen wir ohne Sinons gef?lschten Server auskommen.

Das Geheimnis besteht darin, zu wissen, dass Backbone auf Jquerys $ .ajax () -Funktion zur Implementierung von REST -APIs angewiesen ist. Wir k?nnen die API -Wechselwirkungen abfangen, indem wir diese Funktion stützen. Wenn wir die Funktion stützen, m?chten wir unsere eigene Antwort ersetzen. Die Methode der Stub gibt uns genau diese Gelegenheit. Es sagt Sinon, welche zus?tzlichen Ma?nahmen es ergreifen sollte, wenn der Stub aufgerufen wird. Hier ist ein vollst?ndiger Testfall, um zu überprüfen, ob unsere Sammlung sich selbst mithilfe der Rest -API initialisiert.

<span>var sum = 2 + 2;</span>

fertig!

Wie Sie aus dem folgenden Screenshot sehen k?nnen, haben wir jetzt Code geschrieben, der alle Unit -Testf?lle übergibt. Zumindest ist die Entwicklung abgeschlossen.

Testen w?hrend der Integration

Jetzt, da die clientseitige Entwicklung unserer App abgeschlossen ist (und wir haben die Tests, um dies zu beweisen), k?nnen wir unser JavaScript sicher in ein Quellcode-Management-System einbinden. Es kann dann in den Build -Prozess für die gesamte Anwendung integriert werden. Als Teil dieses Prozesses m?chten wir alle von uns entwickelten Testf?lle ausführen. Dadurch wird sichergestellt, dass der Code, der die endgültige Bereitstellung ausmacht, alle von uns definierten Tests besteht. Es wird auch vor ?kleinen Verbesserungen“ zu dem Code schützen, der versehentlich neue Fehler einführt.

W?hrend des Erstellungsprozesses m?chten wir unsere Tests wahrscheinlich eher aus der Befehlszeile als in einem Webbrowser ausführen. Wir brauchen nicht die Details einzelner Testf?lle, sondern nur eine Zusicherung, dass sie alle bestehen. Node.js macht es einfach genug, diese Anforderung zu erfüllen. Wir müssen nur einige kleine Erg?nzungen zu unseren Quellcode- und Unit -Testcode -Dateien vornehmen.

Unser Code ben?tigt diese Modifikationen, da Node.js globale Variablen unterschiedlich behandelt als Webbrowser. In einem Webbrowser sind JavaScript -Variablen standardm??ig global im Bereich. Node.js dagegen beschr?nkt Variablen standardm??ig auf ihr lokales Modul. In dieser Umgebung kann unser Code nicht in der Lage sein, die von ihm ben?tigten Bibliotheken von Drittanbietern zu finden (JQuery, Undercore und Backbone. Wenn wir zu Beginn die folgenden Aussagen hinzufügen Wir haben diese Aussagen so konstruiert, dass sie im Webbrowser keinen Schaden zufügen, damit wir sie dauerhaft im Code lassen k?nnen.

Wir müssen auch unseren Testcode anpassen. Die Testskripte ben?tigen Zugriff auf ihre eigenen Bibliotheken (JQuery, Chai, Sinon.js und Sinon-Chai). Darüber hinaus müssen wir ein wenig zus?tzlich hinzufügen, um das DOM -Browser -Dokumentobjektmodell (Webbrowser) zu simulieren. Erinnern Sie sich daran, dass unsere Tests zum Klicken auf die Klickhandhabung der Webseite vorübergehend ein ?Fixture“

hinzugefügt haben. Node.js hat natürlich normalerweise keine Webseite. Mit dem JSFom -Knotenpaket k?nnen wir jedoch einen emulieren. Der folgende Code erstellt eine minimale, simulierte Webseite für unsere Tests.

assert<span>.equal(sum, 4, "sum should equal 4");</span>

<span>var sum = 2 + 2;</span>

Die Bedingung, die diese Anweisungen testet, um festzustellen, ob wir in der node.js -Umgebung anstelle eines Webbrowsers ausgeführt werden. In einem Browser sind die zus?tzlichen Aussagen nicht erforderlich, sodass wir sie sicher überspringen k?nnen.

Mit diesen ?nderungen k?nnen wir die vollst?ndige Testsuite aus der Befehlszeile ausführen. Navigieren Sie einfach zum Stammordner des Projekts und führen Sie den Befehl Mokka aus. Das Ergebnis sieht ziemlich vertraut aus.

Natürlich gibt Mokka ein Ausstiegsniveau zurück, um anzugeben, ob alle Tests bestanden haben oder nicht. Dadurch automatisieren wir die Tests im Rahmen eines kontinuierlichen Integrationsprozesses oder einfach als lokales Skript vor dem Kommunikation, um unsere eigene Gesundheit zu erhalten.

Schlussfolgerung

Zu diesem Zeitpunkt haben wir unsere Ziele erreicht. Wir haben eine Unit -Testumgebung, die w?hrend der Entwicklung im Hintergrund l?uft und uns sofort benachrichtigt, wenn ein Test fehlschl?gt. Die Tests werden in einem Webbrowser durchgeführt, sodass wir den vollen Zugriff auf die Entwicklungstools des Browsers haben, w?hrend wir codieren. Die gleichen Tests werden auch gleich gut aus einem Befehlszeilenskript ausgeführt, sodass wir ihre Ausführung w?hrend des Erstellungs- oder Integrationsprozesses automatisieren k?nnen.

Ressourcen

Hier sind die im Artikel verwendeten Testressourcen der Haupteinheiten.

• Befehlszeile JavaScript Ausführungsumgebung: node.js
• JavaScript Unit Testing Framework: Mocha
• Umgebung für Testentwicklung: test’em
• JavaScript Assertion Library: Chai Assertion Library
• Spione, Stubs und Mocks: Sinon.js
• Zus?tzliche Behauptungen: Sinon.js Behauptungen für Chai

h?ufig gestellte Fragen (FAQs) auf Unit -Tests Backbone.js Anwendungen

Was ist die Bedeutung von Unit -Tests in Backbone.js -Anwendungen? Es umfasst das Testen einzelner Komponenten der Software, um sicherzustellen, dass sie wie erwartet funktionieren. Dies hilft bei der Identifizierung und Behebung von Fehler frühzeitig im Entwicklungsprozess und spart so Zeit und Ressourcen. Darüber hinaus erleichtert Unit -Tests das Refactoring von Code, da Entwickler ?nderungen am Code vornehmen und schnell überprüfen k?nnen, ob die ?nderungen vorhandene Funktionen unterbrochen haben. Es verbessert auch das Design des Codes, da das Schreiben von Tests h?ufig zu einer besseren Modularisierung und einem hohen Koh?sion von Code führt.

Wie k?nnen Unit -Tests in Backbone.js mit anderen JavaScript -Frameworks vergleichen? Backbone.js zeichnet sich jedoch aufgrund seiner Flexibilit?t und Einfachheit aus. Es ist nicht vorgesehen, wie Ihre Anwendung strukturiert werden soll, sodass Entwicklern die Freiheit, ihre Anwendungen so zu gestalten, wie sie es für richtig halten. Diese Flexibilit?t erstreckt sich auf Unit -Tests und erm?glicht es Entwicklern, ihre bevorzugten Testwerkzeuge und -methoden auszuw?hlen. Darüber hinaus hat Backbone.js einen kleineren Fu?abdruck im Vergleich zu anderen Frameworks, sodass es für die Testtests schneller und effizienter wird. sind mehrere Tools für Unit -Tests in Backbone.js zur Verfügung. Einige der beliebten sind Mokka, Jasmine und Scherz. Mokka ist ein featurereiches JavaScript-Test-Framework, das Entwicklern eine einfache M?glichkeit bietet, ihre Anwendungen zu testen. Jasmine ist ein verhaltensgetriebenes Entwicklungsrahmen zum Testen von JavaScript-Code. Es stützt sich nicht auf Browser, DOM oder ein JavaScript -Framework, was es ideal zum Testen von Backbone.js -Anwendungen macht. Scherz hingegen ist eine umfassende Testl?sung mit Schwerpunkt auf Einfachheit und Unterstützung für gro?e Webanwendungen.

Wie schreibe ich Unit -Tests für Backbone.js -Anwendungen? Tests für Backbone.JS -Anwendungen umfassen das Erstellen von Testf?llen für jede Komponente der Anwendung. Dies umfasst Modelle, Ansichten und Sammlungen. Jeder Testfall sollte eine spezifische Funktionalit?t der Komponente abdecken und von anderen Testf?llen unabh?ngig sein. Sie k?nnen Test -Frameworks wie Mokka oder Jasmine verwenden, um Ihre Tests zu schreiben. Diese Frameworks bieten Funktionen zum Definieren von Testf?llen, zum Aufbau von Testumgebungen und zum Vorgehen. JS h?ngt vom von Ihnen verwendeten Test -Framework ab. Wenn Sie beispielsweise Mokka verwenden, k?nnen Sie Ihre Tests mit dem MOKA-Befehlszeilen-Tool ausführen. Wenn Sie Jasmine verwenden, k?nnen Sie Ihre Tests mit dem Jasmine Command-Line-Tool ausführen. Diese Tools bieten Optionen, um einzelne Testf?lle, ganze Testsuiten oder alle Tests in Ihrer Anwendung auszuführen. Sie liefern auch detaillierte Berichte über die Ergebnisse der Tests, einschlie?lich der Anzahl der bestandenen, fehlgeschlagenen und übersprungenen Tests. Automatisieren Sie Unit -Tests in Backbone.js. Bei der Automatisierung wird ein CII -System (Continuous Integration) eingerichtet, das Ihre Tests automatisch ausführt, wenn ?nderungen am Code vorgenommen werden. Dies stellt sicher, dass alle durch die ?nderungen eingeführten Fehler sofort gefangen werden. Es stehen mehrere CI -Tools zur Verfügung, wie Jenkins, Travis CI und Circleci, die JavaScript unterstützen und zur Automatisierung von Unit -Tests in Backbone.js.

verwendet werden k?nnen.

Was sind einige Best Practices für Unit -Tests in Backbone.js? und alle m?glichen Kantenf?lle testen. Es ist auch wichtig, Tests zu schreiben, bevor Sie den tats?chlichen Code schreiben, einer Praxis, die als Test-gesteuerte Entwicklung (TDD) bezeichnet wird. Dies stellt sicher, dass Ihr Code prüfbar ist und Ihnen hilft, eine bessere Software zu entwerfen. Bericht, um die Ursache des Versagens zu ermitteln. Die meisten Test -Frameworks bieten detaillierte Fehlermeldungen, mit denen Sie das Problem bestimmen k?nnen. Sie k?nnen auch Debugging -Tools wie Chrome Devtools oder Node.js Debugger verwenden, um Ihren Code zu durchlaufen und Variablen und Funktionsaufrufe zu überprüfen. > Ja, Sie k?nnen Mocks und Stubs in Unit -Tests Backbone.js verwenden. Mocks und Stubs sind gef?lschte Objekte, die das Verhalten realer Objekte simulieren. Sie werden verwendet, um die vom Rest des Systems getestete Komponente zu isolieren. Dies macht Tests zuverl?ssiger und einfacher zu schreiben. Es sind mehrere Bibliotheken verfügbar, wie z. B. Sinon.js, die Funktionen zum Erstellen und Verwalten von Mocks und Stubs bieten. Die Leistung von Unit -Tests in Backbone.js beinhaltet die Optimierung Ihrer Tests und Ihrer Testumgebung. Dies umfasst das Schreiben effizienter Tests, die schnell ausgeführt werden, Tests parallel ausführen und ein schnelles Test -Framework verwenden. Sie k?nnen auch Profiling -Tools verwenden, um langsame Tests und Engp?sse in Ihrem Testprozess zu identifizieren.

Das obige ist der detaillierte Inhalt vonUnit -Tests Backbone.js Anwendungen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!