Testdriven javascript

TESTDRIVEN JAVASCRIPT
DEVELOPMENT

Monday, October 15, 12

WER BIN ICH?

• Sebastian Springer

• 29

• Dipl. Inf. (FH)

• Developer @ Mayﬂower


MARTIN RUPRECHT

• Martin Ruprecht

• 34

• Dipl. Ing. (FH)

• Developer @ Mayﬂower


WER SEID IHR?


AGENDA

• Was ist ein Unittest?

• Welche Testframeworks gibt es?

• Wie funktioniert TDD?

• Was sind Spies, Stubs und Mocks


LET’S GO


GRUNDLAGEN


WAS SIND UNITTESTS?


FEEDBACK

• klar, unmittelbar und wiederkehrend

• je schneller / früher, umso weniger Fehler

• weniger böse Überraschungen


DOKUMENTATION

• Prüfen nicht nur Funktionalität

• Dokumentieren die Verwendung von Schnittstellen


BASIS FÜR CONTINUOUS
INTEGRATION


ANFORDERUNGEN
AN UNITTESTS


ANFORDERUNGEN
• Isoliert

• Nur ein Testfall

• Automatisiert

• Kurz & verständlich

• Hohe Qualität

• Nur relevanter Code

• Schnell


ISOLIERT

• Keine Abhängigkeiten zwischen den Tests

• Keine Abhängigkeiten zu anderen Systemen

• Beeinﬂussen sich nicht gegenseitig (Fehlschläge)

• Reihenfolge ist nicht relevant

• Müssen ein sauberes System hinterlassen


NUR EIN TESTFALL

• Nur eine logische Einheit

• Ein Test schlägt nicht aus verschiedenen Grunden fehl


AUTOMATISIERT

• Keine Nutzerinteraktion

• Durchläufe werden automatisiert gestartet

• Lokale und globale Ausführung


KURZ & VERSTÄNDLICH

• Übersichtlich

• Dokumentierend

• Wartungsfreundlich

• Nicht unnötig komplex


HOHE QUALITÄT

• Langlebige Tests

• Gleiche Qualitätsmaßstäbe wie an normalen Code

• Wartbarkeit

• Erweiterbarkeit


NUR RELEVANTER CODE

• Ziel ist nicht 100% Coverage

• Keine Getter & Setter Testen

• Kosten-Nutzen-Relation

• Keine Software-Prototypen testen


“Tests, die lange laufen, werden
nicht oft ausgeführt”
Kent Beck


SCHNELL

• Langsame Tests - ein Teufelskreis:

• Tests werden nicht ausgefüht,

• Funktionalität wird nicht geprüft,

• Qualität leidet!


WIE SCHREIBE ICH EINEN
TEST?

• 3A - Vorgehen beim Schreiben von Tests:

• Arrange: Erstelle die Objekte

• Act: Interagiere mit ihnen

• Assert: Prüfe das Ergebnis


UNITTESTS FÜR JAVASCRIPT?


FRAMEWORKS


Sinon.js
FRAMEWORKS


jsunit

Sinon.js
FRAMEWORKS


jsunit

Sinon.js
FRAMEWORKS
doh


jsunit

Sinon.js
FRAMEWORKS
JS Test Driver
doh


jsunit
qunit
Sinon.js
FRAMEWORKS
JS Test Driver
doh


jsunit
qunit
Sinon.js
FRAMEWORKS
Jasmine JS Test Driver
doh


jsunit
qunit
Siesta
Sinon.js
FRAMEWORKS
Jasmine JS Test Driver
doh


QUNIT


QUNIT

• http://qunitjs.com/

• Testframework von jQuery

• Standalone Browser Testing

• Integration in IDE und CI


QUNIT - STRUKTUR

• qunit.js

• qunit.css

• index.html

• test.js


QUNIT - INDEX.HTML


QUNIT - TEST.JS


QUNIT - RESULTAT


QUNIT - ASSERTS

• ok()

• equal()

• strictEqual()

• deepEqual()

• not...Equal()


JASMINE

• http://pivotal.github.com/jasmine/

• Unabhängiges Testframework

• BDD in Javascript

• Standalone Browser Testing

• Integration in IDE und CI

• Aktuell der defacto Standard


JASMINE - STRUKTUR
• jasmine.js

• jasmine.css

• jasmine-html.js

• spec/

• src/

• SpecRunner.html


JASMINE - SPECRUNNER


JASMINE - SRC


JASMINE - SPEC


JASMINE - RESULTAT


JASMINE - ASSERTS

• expect(a).toEqual(b);

• expect(a).toMatch(/foo/);

• expect(a).toBeDeﬁned();

• expect(a).toBeTruthy();

• exptect(a).toThrow();

• expect(a).not.toEqual(b);


JSTESTDRIVER


JS TESTDRIVER

• http://code.google.com/p/js-test-driver/

• Testserver in Java

• Remote Browsercapturing

• Integration in die IDE

• Plugins für andere Frameworks

• Kommunikation über HTTP


JSTESTDRIVER - STRUKTUR

• src/

• src-test/

• jsTestDriver.conf


JSTESTDRIVER - SRC


JSTESTDRIVER - SRC-TEST


JSTESTDRIVER - CONFIG


JSTESTDRIVER -
INITIALISIERUNG
• Server start:
java -jar JsTestDriver.jar --port 9876

• Browser öffnen (lokal):
http://localhost:9876/capture

• Browser öffnen (remote):
http://172.16.0.15:9876/capture

• Test start:
java -jar JsTestDriver.jar --tests all


JSTESTDRIVER - RESULTAT


TESTDRIVEN DEVELOPMENT


ONE PROBLEM A TIME


WAS IST TDD?

• Iterativer Ansatz

• Eckpfeiler der agilen Softwareentwicklung

• Gegensatz zum klassichen Vorgehen

• kein großes Design zu Beginn

• Änderungen durch Refactorings


WAS IST TDD

• Besser als: “Debug later programming”

• Führt zu: “Clean code that works”

• Sorgt für: “high code coverage with tests”


WAS IST TDD

• Besser als: “Debug later programming”

• Führt zu: “Clean code that works”

• Sorgt für: “high code coverage with tests”

ABER: muss erlernt und geübt werden


VERKEHRTE WELT

• Klassische
Softwareentwicklung

• Erst der Code

• Dann die Tests
(...wenn noch Zeit ist)


VERKEHRTE WELT

• Klassische • Testgetriebene
Softwareentwicklung Softwareentwicklng

• Erst der Code • Zuerst die Tests
(hier haben wir noch Zeit)

• Dann die Tests • Dann der Code
(...wenn noch Zeit ist)


TDD FEELS GOOD


SETUP
PHPStorm, JsTestDriver, Jasmine


SETUP - PHPSTORM


SETUP - DATEIEN

• jasmine.js

• https://github.com/pivotal/jasmine/downloads

• JasmineAdapter.js

• https://github.com/ibolmo/jasmine-jstd-adapter


SETUP - KONFIGURATION


TDD APPLIED


RED


TDD - RED


GREEN


TDD - GREEN


REFACTOR


TDD - REFACTOR


FRAGEN?


DEMO
Fizz Buzz


FORTGESCHRITTENE THEMEN


TEST PATTERNS
Strategien für das Testen


WAS WIRD GETESTET?

“Everything that could possibly break!”
Ron Jeffries


BABY STEPS
• Ziel: die einfachste Lösung

• Test & Code: so kleine Schritte wie möglich
(nichts überspringen)

• Faustformel: ein Assert pro Step

• Vorteile:

• sehr kurze Feedback-Schleife

• schnelle, übersichtliche Tests


FAKE IT ‘TIL YOU MAKE IT
• Ziel: efﬁziente Entwicklung

• Test & Code: Umsetzung mit ﬁxen Werten

• Faustformel: Duplikate erkennen und entfernen

• Vorteile:

• Tests sehr schnell grün

• Kein Over-Engineering

• Sehr wenig Code


TRIANGULATION

• Ziel:

• Test & Code

• Faustformel

• Vorteile


TRIANGULATION

• Ziel: Operationen abstrahieren

• Faustformel: Mehrere Tests mit verschiedenen Werten für eine
Funktionalität

• Vorteile

• Klare Implementierung

• Saubere Abstraktion


OBVIOUS IMPLEMENTATION

• Ziel: Zeitersparnis, keine unnötigen Tests

• Test & Code: Keine Tests für trivialen Code

• Faustformel: Wird man von einem roten Test überrascht: gehe
zurück zu Los und ziehe keine 2.000 EUR.


THREE OUT OF FOUR

• Ziel: Stets ein Stabiler Stand

• Faustformel: Sei nie mehr als eine Änderung von einem
grünen Test entfernt

• Vorteile:

• Sicherer und stabiler Code


GOLDEN MASTER

• Ziel: Finaler Test

• Test & Code: Manuell geschriebene oder generierte
Erwartung

• Faustformel: Man kann nur mit einem kompletten Systemtest
sicher sein


SPIES, STUBS & MOCKS


SINON.JS


SINON.JS
• http://sinonjs.org/releases/sinon-1.4.2.js

• Testing Framework

• Spies, Stubs und Mocks

• Timers

• Servers

• Sandboxes

• Kann mit anderen Frameworks eingesetzt werden


SPIES


SPIES

The Test Spy is designed to act as an observation point by
recording the method calls made to it by the system under
test as it is exercised.

(xUnit Test Patterns)


SPIES - EIGENSCHAFTEN

• Wrapper um eine Funktion

• Aufrufe werden gespeichert

• Spy-Objekt kann später abgefragt werden

• Sollte nach Verwendung wieder zurückgesetzt werden


SPIES - ERSTELLUNG

• var spy = sinon.spy();
Anonymer Spy - z.B. für Callbacks

• var spy = sinon.spy(myFunc);
Spy um eine Funktion

• var spy = sinon.spy(object, “myFunc”);
Spy um eine Methode eines Objekts


SPIES - API
• spy.called - wurde der Spy aufgerufen

• spy.callCount - wie oft wurde der Spy aufgerufen

• spy.calledWith() - wurde der Spy mit diesen Argumenten
aufgerufen

• spy.withArg() - Spy nur für bestimmte Argumente

• spy.args - Argumente sämtlicher Calls als Array

• spy.threw() - Wurde eine Exception geworfen


SPIES - DEMO


STUBS


STUBS

The Test Stub replaces a real object with a test-speciﬁc object
that feeds the desired indirect inputs into the system under
test.



STUBS - EIGENSCHAFTEN

• Wrapper um eine Funktion (Erweitern die Spy-API)

• Vordeﬁniertes Verhalten

• Wird verwendet um ein bestimmtes Verhalten zu erzwingen

• Vermeiden, dass eine Methode aufgerufen wird (z.B. xhr)


STUBS - ERSTELLUNG

• var stub = sinon.stub();

• var stub = sinon.stub(object, “method”);

• var stub = sinon.stub(object, “method”, func);

• var stub = sinon.stub(object);


STUBS - API

• stub.returns(obj);

• stub.withArgs(“hello world”).returns(42);

• stub.throws(obj);

• stub.yields();


STUBS - YIELDS
Ruft einen Callback mit den angegeben Argumenten auf
var todoList = {
getItem: function (id, callback) {
// ...
}
};

var values = { id: 1, text: "foo", isDone: false };
sinon.stub(todoList, "getItem").yields(values);

todoList.getItem(1, function (item) {
assertEquals(item, { id: 1, text: "foo",
isDone: false });
});

STUBS - DEMO


MOCKS


MOCKS

The mock replaces an object the system under test depends on
with a test-speciﬁc object that veriﬁes it is being used correctly by
the system under test.



MOCKS - EIGENSCHAFTEN

• Wrapper um eine Funktion (wie ein Spy)

• Wird verwendet, um zu prüfen, ob eine Funktion korrekt
benutzt wird

• Generell maximal ein Mock pro Unittest


MOCKS - ERSTELLUNG

• var mock = sinon.mock(obj)


MOCKS - API

• var expectation = expects(‘method’);

• expectation.once

• expectation.atLeast(n)

• expectation.atMost(m)

• expectation.withArgs(arg, arg,...)


TIMERS & FAKE SERVERS


TIMERS

• Für zeitkritische Tests

• Browserzeit ist nicht Zuverlässig

• Für solide Tests braucht man seine eigene Uhr


TIMERS


SINON HÄLT DIE ZEIT AN


TIMERS IN SINON

• var clock = sinon.useFakeTimers();

• var clock = sinon.useFakeTimers(now);

• clock.tick(ms);

• clock.restore();


TIMER


FAKE SERVER


FAKE SERVER

• Tests unabhängig vom Server

• Rückmeldung vom Server festlegen

• Überschreibt das native XMLHttpReqest und ActiveXObject


FAKE SERVER - API

• var server = sinon.fakeServer.create();

• server.respondWith(meth, url, response);

• server.respond();

• server.restore();


WIE GEHT ES JETZT WEITER?

• Nimm teil an einem Coding Dojo

• Führe Coding Katas durch

• Pair Programming

• Austausch mit anderen Entwicklern


TIPPS & TRICKS


CHEAT SHEET
• Write a failing Test • Triangulate

• Write the simplest code to • Keep your test and model
test code separate

• Refactor to remove duplication • Isolate your tests

• Write the assertion ﬁrst and • Test should test one thing
work backwards
• Don’t refactor with a failing
• See the test fail test

• Write meaningful tests • Maintain your Tests


KONTAKT
Sebastian Springer Martin Ruprecht
sebastian.springer@mayflower.de martin.ruprecht@mayflower.de

Mayflower GmbH Mayflower GmbH
Mannhardtstr. 6 Mannhardtstr. 6
80538 München 80538 München
Deutschland Deutschland

@basti_springer @mrupilo

https://github.com/sspringer82 https://github.com/mruprecht


Testdriven javascript

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (14)

Mehr von Sebastian Springer

Mehr von Sebastian Springer (20)

Testdriven javascript