webinar test-driven javascript

TEST-DRIVEN JAVASCRIPTFür mehr Qualität in JavaScript-Applikationen

Wednesday, January 23, 13

WER BIN ICH?

• Sebastian Springer

• 30

•Dipl. Inf. (FH)

• Teamleiter @ Mayflower München

•Nebenbei: JavaScript-Entwickler

•@basti_springer


WAS ERWARTET EUCH?

?Wednesday, January 23, 13

WAS ERWARTET EUCH?

•Was ist TDD?

?Wednesday, January 23, 13

WAS ERWARTET EUCH?

•Was ist TDD?

?•Warum TDD?


WAS ERWARTET EUCH?

•Was ist TDD?

?•Warum TDD?•Was benötige ich dafür?


WAS ERWARTET EUCH?

•Was ist TDD?

?•Wie funktioniert’s?

•Warum TDD?•Was benötige ich dafür?


WAS�� IST�� TDD?WARUM�� TDD?VORAUSSETZUNGEN?WIE�� FUNKTIONIERT’S?


WAS IST TDD?• Angewandtes Softwaredesign und -entwicklung

• Erst Tests, dann den Code

• Red, Green, Refactor

• Clean Code that works


TDD�� ist�� doof


DIE SCHATTENSEITEN• Verständnis

•Disziplin und Konsequenz

• Einstiegshürde

• Anfänglich langsame Geschwindigkeit



✓


Weil’s�� geht!


Das Problem verstehen


Sicherheit für Refactorings


Schnelles Feedback


Software muss getestet werden


Software muss getestet werden

entweder manuell oder automatisch


Dokumentation


Basis für Weiterentwicklung


Besserer Code


Weniger Bugs


Spaß an der Arbeit


Qualität und Lauffähigkeit



✓✓


IDE


FRAMEWORK


BROWSER


Gibt’s�� das�� nicht�� in�� besser?


INTEGRATION


INTEGRATION

JsTestDriver Plugin


JSTESTDRIVER


+ = ♥



✓✓✓


DAS BEISPIEL:FIZZ BUZZ


FIZZ BUZZ

• Es wird eine Zahl eingegeben.

• Ist die Zahl durch 3 teilbar, ist das Ergebnis “fizz”.

• Ist die Zahl durch 5 teilbar, ist das Ergebnis “buzz”.

• Ist die Zahl sowohl durch 3 als auch durch 5 teilbar, ist das Ergebnis “fizzbuzz”.


FIZZ BUZZ1 1 11 11 21 fizz2 2 12 fizz 22 223 fizz 13 13 23 234 4 14 14 24 fizz5 buzz 15 fizzbuzz 25 buzz6 fizz 16 16 26 267 7 17 17 27 fizz8 8 18 fizz 28 289 fizz 19 19 29 2910 buzz 20 buzz 30 fizzbuzz


SETUP


FIZZBUZZ.JSTD

load: - lib/jasmine.js - lib/JasmineAdapter.js - spec/FizzBuzz.spec.js - src/FizzBuzz.js

• YAML-Format

• Speicherorte der verschiedenen Dateien


Na�� dann�� mal�� los!


TEST FIRST

• Erst den Test, dann den Quellcode

• Anforderungen in Test übersetzen

•One problem a time


describe("FizzBuzz", function () { "use strict";

it("should return 1, if 1 is provided", function () { expect(fizzbuzz(1)).toEqual(1); });

});


red


EINFACHSTE LÖSUNG

• Ziel: Der Test muss grün werden.

• Fokus auf die aktuelle Problemstellung


FAKE IT ‘TIL YOU MAKE IT

• Umsetzung mit fixen Werten

• Tests werden sehr schnell grün

•Wenig Code

• Kein Over-Engineering


var fizzbuzz = function () { "use strict"; return 1;};


green


TRIANGULATION

•Mehrere Tests mit verschiedenen Werten

• Klare Implementierung

• Saubere Abstraktion

• Tests mit Grenzwerten


it("should return 2, if 2 is provided", function () { expect(fizzbuzz(2)).toEqual(2);});


red


var fizzbuzz = function (n) { "use strict"; return n;};


green


OBVIOUS IMPLEMENTATION

• Keine unnötigen Tests

•Wenn 1 und 2 funktionieren, sollten auch alle weiteren Zahlen funktionieren.

• Zu viel Aufwand für Tests


BABY STEPS

•Die kleinst möglichen Schritte

• Sehr kurze Feedback-Scheifen

• Schnelle, übersichtliche Tests


it("should return fizz, if 3 is provided", function () { expect(fizzbuzz(3)).toEqual('fizz');});


red


var fizzbuzz = function (n) { "use strict";

if (n === 3) { return 'fizz'; }

return n;};


green


THREE OUT OF FOUR

• Stabiler Codestand

•Maximal eine Änderung entfernt von grünen Tests


YAGNI

• You Ain’t Gonna Need It

• Kein Code für zukünftige Probleme

• Fokus auf das aktuelle Problem


it("should return fizz, if 6 is provided", function () { expect(fizzbuzz(6)).toEqual('fizz');});


red



if (n === 3 || n === 6) { return 'fizz'; }

if (n === 5) { return 'buzz'; }

return n;};


green


REFACTOR

• Stellen, die verbessert werden können, identifizieren

• Anhand der bestehenden Tests den Code umbauen



if (n % 3 === 0) { return 'fizz'; }

if (n === 5) { return 'buzz'; }

return n;};


green


REMOVE DUPLICATION

• Bessere Wartbarkeit

• Übersichtlicher Quellcode

• Teure Weiterentwicklung


GOLDEN MASTER

• kompletter Systemtest

• Generierter oder manueller Test

• bei umfangreicheren Workflows sehr aufwändig


describe("FizzBuzz", function () { "use strict";

var map = [ '', 1, 2, 'fizz', 4, 'buzz', 'fizz', 7, 8, 'fizz', 'buzz', 11, 'fizz', 13, 14, 'fizzbuzz', 16, 17, 'fizz', 19, 'buzz', 'fizz', 22, 23, 'fizz', 'buzz', 26, 'fizz', 28, 29, 'fizzbuzz' ], i, bindFunc,

func = function (x, y) { expect(fizzbuzz(x)).toEqual(y); };

for (i = 1; i < map.length; i += 1) { bindFunc = func.bind(this, i, map[i]); it("should return " + map[i] + " if " + i + " is provided", bindFunc); }});


green


UND JETZT?

•Nimm teil an einem Coding Dojo

• Führe Coding Katas durch

• Pair Programming

• Austausch mit anderen Entwicklern


CHEAT SHEET• Write a failing Test

• Write the simplest code to test

• Refactor to remove duplication

• Write the assertion first and work backwards

• See the test fail

• Write meaningful tests

• Triangulate

• Keep your test and model code separate

• Isolate your tests

• Test should test one thing

• Don’t refactor with a failing test

• Maintain your Tests


Fragen?


VIELEN DANK!Sebastian Springer

Mayflower GmbHMannhardtstr. 680538 MünchenDeutschland

@basti_springer

https://github.com/sspringer82




webinar test-driven javascript

Technology

bentige ich dafr

erwartet euch

ist tdd

warum tdd

return fizz

return fizz

return buzz

map