Macoun
⌘
1
Unit Tests für Totalverweigerer
Peter Hauke, Ingo Kasprzak
2
Hinweis
•Unit Tests für Totalverweigerer
•Spieleentwicklung mit Sprite Kit (Terrassensaal)
•B.L.I.N.K. (Kleiner Saal)
3
Ablauf
•Theorie
•Theorie mit etwas Praxis
•Praxis
•Demos
4
Testing
5
Varianten von Testing ...
•Verbreitete Tests:
• Integrationstest
• Systemtests
• Akzeptanztest
Black Box Tests
•Problem be...
... eine weitere
Unit Tests
•Test funktionaler Einzelteile (Module)
•Validierung auf statische Bedingungen
•Idee:
• Einzel...
Ja und nun?
8
Grundidee
Kleine Teile testen
•Tests ohne Abhängigkeiten von:
• Benutzereingaben
• Konfiguration des Host
• Externen Daten ...
Ergebnis
Hohe Testabdeckung
•Vielzahl von Test, die
• jederzeit wiederholt werden können
• ständig wiederholt werden
•Stet...
Ich versteh es immer noch nicht
11
Test Driven Development
Test First Development
•Ansatz:
• Test schreiben
• Code schreiben der Test genügt
• Refactoring
•w...
Test Driven Development
Voraussetzungen
•Genaue Analyse der Anforderungen vor Entwicklung
•Kleinteilige Problemstellungen ...
Test Driven Development
Und so gehts ... (1)
•Analyse
•ein Microfeature identifizieren
•Randbedingungen für Microfeature er...
Test Driven Development
Und so gehts ... (2)
•Test starten
• fail: Code fehlt noch
• pass: Microfeature bereits implementi...
Test Driven Development
Und so gehts ... (3)
•Code so lang anpassen, bis Test erfolgreich
• Just Barely Good Enough™
•Refa...
Test Driven Development
Beispiel:Taschenrechner
•Analyse:
• Methoden zur Berechnung
•Microfeature:
• Addition zweier Zahle...
Änderung der Herangehensweise
•Weg von Gedanken „Wie kann ich das debuggen?“
•Über „Wie kann ich einenTest dafür schreiben...
Vorteile
•Code wird kleinteilig
•Code wird kleinteilig tesbar
•Zeitnahe Problembehebung
•Weniger Code
•Sicherheit beim Ref...
Der lange Weg
•Unit Tests ausprobieren
•kleine Tests schreiben
•oder auch: erst Code, dann Test schreiben
•typisch: man sc...
Nachteile
•(naja) hohes Anforderungsverständnis
•nur erkannte Randbedingungen spiegeln sich in Tests wieder
•Testcode, der...
Nettigkeiten
•Zwang, die Anforderungen zu verstehen
•Teamarbeit: Tester - Coder
•weniger überflüssiger Code
•Tests dienen d...
Worauf teste ich?
23
Worauf teste ich?
XCTest/XCTestAssertionsImpl.h (1)
XCTFail(format...)
XCTAssertNil(a1, format...)
XCTAssertNotNil(a1, for...
Worauf teste ich?
XCTest/XCTestAssertionsImpl.h (2)
XCTAssertThrows(expression, format...)
XCTAssertThrowsSpecific(express...
Worauf teste ich?
XCTest/XCTestAssertionsImpl.h (3)
XCTAssertNil(a1, format...)
XCTAssertNotNil(a1, format...)
XCTAssertTr...
Worauf teste ich?
XCTest/XCTestAssertionsImpl.h (4)
XCTAssertEqualObjects(a1, a2, format...)
XCTAssertNotEqualObjects(a1, ...
Demo
28
Demos
•Ganz einfach
•Unit Test nachrüsten
•TicTacToe mit Überraschungen
29
Ganz einfach
•Simple Calculator
30
Unit Test nachrüsten
•Framework in Xcode 5: XCTest
31
Projekt in Xcode 5
32
Target hinzufügen
33
Testing Bundle
34
Target Namen wählen
35
Das war‘s ...
36
TicTacToe
•Demo von Macoun 2012
•Unit Test nachgerüstet
•überraschende Ergebnisse
37
Fragen?
38
Tipp
Der wichtigste Test überhaupt ist der,
den man zuerst schreibt.
39
Buchempfehlung
Graham Lee
„Test-Driven iOS Development“
40
One more thing
http://www.0x02100.de
41
Vielen Dank
42
Macoun
⌘
43
Nächste SlideShare
Wird geladen in …5
×

Unit Tests für Totalverweigerer

1.685 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.685
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
47
Aktionen
Geteilt
0
Downloads
10
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Unit Tests für Totalverweigerer

  1. 1. Macoun ⌘ 1
  2. 2. Unit Tests für Totalverweigerer Peter Hauke, Ingo Kasprzak 2
  3. 3. Hinweis •Unit Tests für Totalverweigerer •Spieleentwicklung mit Sprite Kit (Terrassensaal) •B.L.I.N.K. (Kleiner Saal) 3
  4. 4. Ablauf •Theorie •Theorie mit etwas Praxis •Praxis •Demos 4
  5. 5. Testing 5
  6. 6. Varianten von Testing ... •Verbreitete Tests: • Integrationstest • Systemtests • Akzeptanztest Black Box Tests •Problem bei allen: Debugging 6
  7. 7. ... eine weitere Unit Tests •Test funktionaler Einzelteile (Module) •Validierung auf statische Bedingungen •Idee: • Einzelteile genügen Spezifikationen • Gesamtheit der Einzelteile genügt Spezifikation 7
  8. 8. Ja und nun? 8
  9. 9. Grundidee Kleine Teile testen •Tests ohne Abhängigkeiten von: • Benutzereingaben • Konfiguration des Host • Externen Daten (Datenbanken, Server) • anderen Tests •Module liefern zu diskreten Eingaben reproduzierbare Ergebnisse 9
  10. 10. Ergebnis Hohe Testabdeckung •Vielzahl von Test, die • jederzeit wiederholt werden können • ständig wiederholt werden •StetigeValidierung von existierendem Code •Macoun 2013 „96%Testabdeckung“ (Maxim Zaks) 10
  11. 11. Ich versteh es immer noch nicht 11
  12. 12. Test Driven Development Test First Development •Ansatz: • Test schreiben • Code schreiben der Test genügt • Refactoring •wenig überflüssiger Code & hohe Testabdeckung 12
  13. 13. Test Driven Development Voraussetzungen •Genaue Analyse der Anforderungen vor Entwicklung •Kleinteilige Problemstellungen identifizieren (Microfeatures) • kleinere Microfeatures - einfachere Tests 13
  14. 14. Test Driven Development Und so gehts ... (1) •Analyse •ein Microfeature identifizieren •Randbedingungen für Microfeature erkennen •Test schreiben 14
  15. 15. Test Driven Development Und so gehts ... (2) •Test starten • fail: Code fehlt noch • pass: Microfeature bereits implementiert •Code schreiben •Test starten 15
  16. 16. Test Driven Development Und so gehts ... (3) •Code so lang anpassen, bis Test erfolgreich • Just Barely Good Enough™ •Refactor •Testen 16
  17. 17. Test Driven Development Beispiel:Taschenrechner •Analyse: • Methoden zur Berechnung •Microfeature: • Addition zweier Zahlen •Randbedingungen: • Eingabe numerisch und nicht nil 17
  18. 18. Änderung der Herangehensweise •Weg von Gedanken „Wie kann ich das debuggen?“ •Über „Wie kann ich einenTest dafür schreiben?“ •Zu „Wie kann ich beweisen, dass mein Code den Anforderungen genügt?“ 18
  19. 19. Vorteile •Code wird kleinteilig •Code wird kleinteilig tesbar •Zeitnahe Problembehebung •Weniger Code •Sicherheit beim Refactor •Spätere Änderungen am Code transparenter 19
  20. 20. Der lange Weg •Unit Tests ausprobieren •kleine Tests schreiben •oder auch: erst Code, dann Test schreiben •typisch: man schreibt Tests, die zum Code passen könnten •Lernkurve enorm 20
  21. 21. Nachteile •(naja) hohes Anforderungsverständnis •nur erkannte Randbedingungen spiegeln sich in Tests wieder •Testcode, der nicht in die App gelangt •Tests garantieren keine Fehlerfreiheit •Problem bei Datenbanken, Netzwerk, Nebenläufigkeit 21
  22. 22. Nettigkeiten •Zwang, die Anforderungen zu verstehen •Teamarbeit: Tester - Coder •weniger überflüssiger Code •Tests dienen der Dokumentation •Last but not least: Viele Grüne Tests ergeben ein gutes Gefühl 22
  23. 23. Worauf teste ich? 23
  24. 24. Worauf teste ich? XCTest/XCTestAssertionsImpl.h (1) XCTFail(format...) XCTAssertNil(a1, format...) XCTAssertNotNil(a1, format...) XCTAssert(expression, format...) XCTAssertTrue(expression, format...) XCTAssertFalse(expression, format...) XCTAssertEqualObjects(a1, a2, format...) XCTAssertNotEqualObjects(a1, a2, format...) XCTAssertEqual(a1, a2, format...) XCTAssertNotEqual(a1, a2, format...) XCTAssertEqualWithAccuracy(a1, a2, accuracy, format...) XCTAssertNotEqualWithAccuracy(a1, a2, accuracy, format...) 24
  25. 25. Worauf teste ich? XCTest/XCTestAssertionsImpl.h (2) XCTAssertThrows(expression, format...) XCTAssertThrowsSpecific(expression, specificException, format...) XCTAssertThrowsSpecificNamed(expression, specificException, exception_name, format...) XCTAssertNoThrow(expression, format...) XCTAssertNoThrowSpecific(expression, specificException, format...) XCTAssertNoThrowSpecificNamed(expression, specificException, exception_name, format...) 25
  26. 26. Worauf teste ich? XCTest/XCTestAssertionsImpl.h (3) XCTAssertNil(a1, format...) XCTAssertNotNil(a1, format...) XCTAssertTrue(expression, format...) XCTAssertFalse(expression, format...) 26
  27. 27. Worauf teste ich? XCTest/XCTestAssertionsImpl.h (4) XCTAssertEqualObjects(a1, a2, format...) XCTAssertNotEqualObjects(a1, a2, format...) XCTAssertEqual(a1, a2, format...) XCTAssertNotEqual(a1, a2, format...) XCTAssertEqualWithAccuracy(a1, a2, accuracy, format...) XCTAssertNotEqualWithAccuracy(a1, a2, accuracy, format...) 27
  28. 28. Demo 28
  29. 29. Demos •Ganz einfach •Unit Test nachrüsten •TicTacToe mit Überraschungen 29
  30. 30. Ganz einfach •Simple Calculator 30
  31. 31. Unit Test nachrüsten •Framework in Xcode 5: XCTest 31
  32. 32. Projekt in Xcode 5 32
  33. 33. Target hinzufügen 33
  34. 34. Testing Bundle 34
  35. 35. Target Namen wählen 35
  36. 36. Das war‘s ... 36
  37. 37. TicTacToe •Demo von Macoun 2012 •Unit Test nachgerüstet •überraschende Ergebnisse 37
  38. 38. Fragen? 38
  39. 39. Tipp Der wichtigste Test überhaupt ist der, den man zuerst schreibt. 39
  40. 40. Buchempfehlung Graham Lee „Test-Driven iOS Development“ 40
  41. 41. One more thing http://www.0x02100.de 41
  42. 42. Vielen Dank 42
  43. 43. Macoun ⌘ 43

×