13. ANFORDERUNGEN
• Isoliert
• Nur ein Testfall
• Automatisiert
• Kurz & verständlich
• Hohe Qualität
• Nur relevanter Code
• Schnell
Monday, October 15, 12
14. ISOLIERT
• Keine Abhängigkeiten zwischen den Tests
• Keine Abhängigkeiten zu anderen Systemen
• Beeinflussen sich nicht gegenseitig (Fehlschläge)
• Reihenfolge ist nicht relevant
• Müssen ein sauberes System hinterlassen
Monday, October 15, 12
15. NUR EIN TESTFALL
• Nur eine logische Einheit
• Ein Test schlägt nicht aus verschiedenen Grunden fehl
Monday, October 15, 12
16. AUTOMATISIERT
• Keine Nutzerinteraktion
• Durchläufe werden automatisiert gestartet
• Lokale und globale Ausführung
Monday, October 15, 12
17. KURZ & VERSTÄNDLICH
• Übersichtlich
• Dokumentierend
• Wartungsfreundlich
• Nicht unnötig komplex
Monday, October 15, 12
18. HOHE QUALITÄT
• Langlebige Tests
• Gleiche Qualitätsmaßstäbe wie an normalen Code
• Wartbarkeit
• Erweiterbarkeit
Monday, October 15, 12
19. NUR RELEVANTER CODE
• Ziel ist nicht 100% Coverage
• Keine Getter & Setter Testen
• Kosten-Nutzen-Relation
• Keine Software-Prototypen testen
Monday, October 15, 12
20. “Tests, die lange laufen, werden
nicht oft ausgeführt”
Kent Beck
Monday, October 15, 12
21. SCHNELL
• Langsame Tests - ein Teufelskreis:
• Tests werden nicht ausgefüht,
• Funktionalität wird nicht geprüft,
• Qualität leidet!
Monday, October 15, 12
22. WIE SCHREIBE ICH EINEN
TEST?
• 3A - Vorgehen beim Schreiben von Tests:
• Arrange: Erstelle die Objekte
• Act: Interagiere mit ihnen
• Assert: Prüfe das Ergebnis
Monday, October 15, 12
40. JASMINE
• http://pivotal.github.com/jasmine/
• Unabhängiges Testframework
• BDD in Javascript
• Standalone Browser Testing
• Integration in IDE und CI
• Aktuell der defacto Standard
Monday, October 15, 12
41. JASMINE - STRUKTUR
• jasmine.js
• jasmine.css
• jasmine-html.js
• spec/
• src/
• SpecRunner.html
Monday, October 15, 12
49. 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
Monday, October 15, 12
59. WAS IST TDD?
• Iterativer Ansatz
• Eckpfeiler der agilen Softwareentwicklung
• Gegensatz zum klassichen Vorgehen
• kein großes Design zu Beginn
• Änderungen durch Refactorings
Monday, October 15, 12
60. WAS IST TDD
• Besser als: “Debug later programming”
• Führt zu: “Clean code that works”
• Sorgt für: “high code coverage with tests”
Monday, October 15, 12
61. 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
Monday, October 15, 12
62. VERKEHRTE WELT
• Klassische
Softwareentwicklung
• Erst der Code
• Dann die Tests
(...wenn noch Zeit ist)
Monday, October 15, 12
63. 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)
Monday, October 15, 12
84. TEST PATTERNS
Strategien für das Testen
Monday, October 15, 12
85. WAS WIRD GETESTET?
“Everything that could possibly break!”
Ron Jeffries
Monday, October 15, 12
86. 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
Monday, October 15, 12
87. FAKE IT ‘TIL YOU MAKE IT
• Ziel: effiziente Entwicklung
• Test & Code: Umsetzung mit fixen Werten
• Faustformel: Duplikate erkennen und entfernen
• Vorteile:
• Tests sehr schnell grün
• Kein Over-Engineering
• Sehr wenig Code
Monday, October 15, 12
88. TRIANGULATION
• Ziel:
• Test & Code
• Faustformel
• Vorteile
Monday, October 15, 12
89. TRIANGULATION
• Ziel: Operationen abstrahieren
• Faustformel: Mehrere Tests mit verschiedenen Werten für eine
Funktionalität
• Vorteile
• Klare Implementierung
• Saubere Abstraktion
Monday, October 15, 12
90. 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.
Monday, October 15, 12
91. 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
Monday, October 15, 12
92. GOLDEN MASTER
• Ziel: Finaler Test
• Test & Code: Manuell geschriebene oder generierte
Erwartung
• Faustformel: Man kann nur mit einem kompletten Systemtest
sicher sein
Monday, October 15, 12
95. 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
Monday, October 15, 12
97. 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)
Monday, October 15, 12
98. SPIES - EIGENSCHAFTEN
• Wrapper um eine Funktion
• Aufrufe werden gespeichert
• Spy-Objekt kann später abgefragt werden
• Sollte nach Verwendung wieder zurückgesetzt werden
Monday, October 15, 12
99. 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
Monday, October 15, 12
100. 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
Monday, October 15, 12
103. STUBS
The Test Stub replaces a real object with a test-specific object
that feeds the desired indirect inputs into the system under
test.
(xUnit Test Patterns)
Monday, October 15, 12
104. STUBS - EIGENSCHAFTEN
• Wrapper um eine Funktion (Erweitern die Spy-API)
• Vordefiniertes Verhalten
• Wird verwendet um ein bestimmtes Verhalten zu erzwingen
• Vermeiden, dass eine Methode aufgerufen wird (z.B. xhr)
Monday, October 15, 12
105. STUBS - ERSTELLUNG
• var stub = sinon.stub();
• var stub = sinon.stub(object, “method”);
• var stub = sinon.stub(object, “method”, func);
• var stub = sinon.stub(object);
Monday, October 15, 12
106. STUBS - API
• stub.returns(obj);
• stub.withArgs(“hello world”).returns(42);
• stub.throws(obj);
• stub.yields();
Monday, October 15, 12
107. 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 });
});
Monday, October 15, 12
110. MOCKS
The mock replaces an object the system under test depends on
with a test-specific object that verifies it is being used correctly by
the system under test.
(xUnit Test Patterns)
Monday, October 15, 12
111. 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
Monday, October 15, 12
121. FAKE SERVER
• Tests unabhängig vom Server
• Rückmeldung vom Server festlegen
• Überschreibt das native XMLHttpReqest und ActiveXObject
Monday, October 15, 12
122. FAKE SERVER - API
• var server = sinon.fakeServer.create();
• server.respondWith(meth, url, response);
• server.respond();
• server.restore();
Monday, October 15, 12
125. WIE GEHT ES JETZT WEITER?
• Nimm teil an einem Coding Dojo
• Führe Coding Katas durch
• Pair Programming
• Austausch mit anderen Entwicklern
Monday, October 15, 12
127. 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 first 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
Monday, October 15, 12
128. 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
Monday, October 15, 12