Webinar Test-Driven JavaScript

971 views

Published on

Für mehr Qualität in JavaScript-Applikationen

Recording verfügbar unter: http://www.mayflower.de/de/ressourcen/webinare/archiv/test-driven-javascript

Published in: Technology
1 Comment
1 Like
Statistics
Notes
  • War ein sehr schönes Webinar! Wer die Webinaraufzeichnung noch einmal komplett mit Ton ansehen möchte, findet diese hier: http://www.mayflower.de/de/ressourcen/webinare/archiv/test-driven-javascript
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
971
On SlideShare
0
From Embeds
0
Number of Embeds
126
Actions
Shares
0
Downloads
8
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

Webinar Test-Driven JavaScript

  1. 1. TEST-DRIVEN JAVASCRIPT Für mehr Qualität in JavaScript-ApplikationenWednesday, January 23, 13
  2. 2. WER BIN ICH? • Sebastian Springer • 30 • Dipl. Inf. (FH) • Teamleiter @ Mayflower München • Nebenbei: JavaScript-Entwickler • @basti_springerWednesday, January 23, 13
  3. 3. WAS ERWARTET EUCH? ?Wednesday, January 23, 13
  4. 4. WAS ERWARTET EUCH? • Was ist TDD? ?Wednesday, January 23, 13
  5. 5. WAS ERWARTET EUCH? • Was ist TDD? ? • Warum TDD?Wednesday, January 23, 13
  6. 6. WAS ERWARTET EUCH? • Was ist TDD? ? • Warum TDD? • Was benötige ich dafür?Wednesday, January 23, 13
  7. 7. WAS ERWARTET EUCH? • Was ist TDD? ? • Warum TDD? • Was benötige ich dafür? • Wie funktioniert’s?Wednesday, January 23, 13
  8. 8. WAS
  9. 9.  IST
  10. 10.  TDD? WARUM
  11. 11.  TDD? VORAUSSETZUNGEN? WIE
  12. 12.  FUNKTIONIERT’S?Wednesday, January 23, 13
  13. 13. WAS IST TDD? • Angewandtes Softwaredesign und -entwicklung • Erst Tests, dann den Code • Red, Green, Refactor • Clean Code that worksWednesday, January 23, 13
  14. 14. TDD
  15. 15.  ist
  16. 16.  doofWednesday, January 23, 13
  17. 17. DIE SCHATTENSEITEN • Verständnis • Disziplin und Konsequenz • Einstiegshürde • Anfänglich langsame GeschwindigkeitWednesday, January 23, 13
  18. 18. WAS
  19. 19.  IST
  20. 20.  TDD? ✓ WARUM
  21. 21.  TDD? VORAUSSETZUNGEN? WIE
  22. 22.  FUNKTIONIERT’S?Wednesday, January 23, 13
  23. 23. Weil’s
  24. 24.  geht!Wednesday, January 23, 13
  25. 25. Das Problem verstehenWednesday, January 23, 13
  26. 26. Sicherheit für RefactoringsWednesday, January 23, 13
  27. 27. Schnelles FeedbackWednesday, January 23, 13
  28. 28. Software muss getestet werdenWednesday, January 23, 13
  29. 29. Software muss getestet werden entweder manuell oder automatischWednesday, January 23, 13
  30. 30. DokumentationWednesday, January 23, 13
  31. 31. Basis für WeiterentwicklungWednesday, January 23, 13
  32. 32. Besserer CodeWednesday, January 23, 13
  33. 33. Weniger BugsWednesday, January 23, 13
  34. 34. Spaß an der ArbeitWednesday, January 23, 13
  35. 35. Qualität und LauffähigkeitWednesday, January 23, 13
  36. 36. WAS
  37. 37.  IST
  38. 38.  TDD? ✓ WARUM
  39. 39.  TDD? ✓ VORAUSSETZUNGEN? WIE
  40. 40.  FUNKTIONIERT’S?Wednesday, January 23, 13
  41. 41. IDEWednesday, January 23, 13
  42. 42. FRAMEWORKWednesday, January 23, 13
  43. 43. BROWSERWednesday, January 23, 13
  44. 44. Gibt’s
  45. 45.  das
  46. 46.  nicht
  47. 47.  in
  48. 48.   besser?Wednesday, January 23, 13
  49. 49. INTEGRATIONWednesday, January 23, 13
  50. 50. INTEGRATION JsTestDriver PluginWednesday, January 23, 13
  51. 51. JSTESTDRIVERWednesday, January 23, 13
  52. 52. + = ♥Wednesday, January 23, 13
  53. 53. WAS
  54. 54.  IST
  55. 55.  TDD? ✓ WARUM
  56. 56.  TDD? ✓ VORAUSSETZUNGEN? ✓ WIE
  57. 57.  FUNKTIONIERT’S?Wednesday, January 23, 13
  58. 58. DAS BEISPIEL: FIZZ BUZZWednesday, January 23, 13
  59. 59. 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”.Wednesday, January 23, 13
  60. 60. FIZZ BUZZ 1 1 11 11 21 fizz 2 2 12 fizz 22 22 3 fizz 13 13 23 23 4 4 14 14 24 fizz 5 buzz 15 fizzbuzz 25 buzz 6 fizz 16 16 26 26 7 7 17 17 27 fizz 8 8 18 fizz 28 28 9 fizz 19 19 29 29 10 buzz 20 buzz 30 fizzbuzzWednesday, January 23, 13
  61. 61. SETUPWednesday, January 23, 13
  62. 62. FIZZBUZZ.JSTD load: - lib/jasmine.js - lib/JasmineAdapter.js - spec/FizzBuzz.spec.js - src/FizzBuzz.js • YAML-Format • Speicherorte der verschiedenen DateienWednesday, January 23, 13
  63. 63. Wednesday, January 23, 13
  64. 64. Na
  65. 65.  dann
  66. 66.  mal
  67. 67.  los!Wednesday, January 23, 13
  68. 68. TEST FIRST • Erst den Test, dann den Quellcode • Anforderungen in Test übersetzen • One problem a timeWednesday, January 23, 13
  69. 69. describe(FizzBuzz, function () { use strict; it(should return 1, if 1 is provided, function () { expect(fizzbuzz(1)).toEqual(1); }); });Wednesday, January 23, 13
  70. 70. redWednesday, January 23, 13
  71. 71. EINFACHSTE LÖSUNG • Ziel: Der Test muss grün werden. • Fokus auf die aktuelle ProblemstellungWednesday, January 23, 13
  72. 72. FAKE IT ‘TIL YOU MAKE IT • Umsetzung mit fixen Werten • Tests werden sehr schnell grün • Wenig Code • Kein Over-EngineeringWednesday, January 23, 13
  73. 73. var fizzbuzz = function () { use strict; return 1; };Wednesday, January 23, 13
  74. 74. greenWednesday, January 23, 13
  75. 75. TRIANGULATION • Mehrere Tests mit verschiedenen Werten • Klare Implementierung • Saubere Abstraktion • Tests mit GrenzwertenWednesday, January 23, 13
  76. 76. it(should return 2, if 2 is provided, function () { expect(fizzbuzz(2)).toEqual(2); });Wednesday, January 23, 13
  77. 77. redWednesday, January 23, 13
  78. 78. var fizzbuzz = function (n) { use strict; return n; };Wednesday, January 23, 13
  79. 79. greenWednesday, January 23, 13
  80. 80. OBVIOUS IMPLEMENTATION • Keine unnötigen Tests • Wenn 1 und 2 funktionieren, sollten auch alle weiteren Zahlen funktionieren. • Zu viel Aufwand für TestsWednesday, January 23, 13
  81. 81. BABY STEPS • Die kleinst möglichen Schritte • Sehr kurze Feedback-Scheifen • Schnelle, übersichtliche TestsWednesday, January 23, 13
  82. 82. it(should return fizz, if 3 is provided, function () { expect(fizzbuzz(3)).toEqual(fizz); });Wednesday, January 23, 13
  83. 83. redWednesday, January 23, 13
  84. 84. var fizzbuzz = function (n) { use strict; if (n === 3) { return fizz; } return n; };Wednesday, January 23, 13
  85. 85. greenWednesday, January 23, 13
  86. 86. THREE OUT OF FOUR • Stabiler Codestand • Maximal eine Änderung entfernt von grünen TestsWednesday, January 23, 13
  87. 87. YAGNI • You Ain’t Gonna Need It • Kein Code für zukünftige Probleme • Fokus auf das aktuelle ProblemWednesday, January 23, 13
  88. 88. it(should return fizz, if 6 is provided, function () { expect(fizzbuzz(6)).toEqual(fizz); });Wednesday, January 23, 13
  89. 89. redWednesday, January 23, 13
  90. 90. var fizzbuzz = function (n) { use strict; if (n === 3 || n === 6) { return fizz; } if (n === 5) { return buzz; } return n; };Wednesday, January 23, 13
  91. 91. greenWednesday, January 23, 13
  92. 92. REFACTOR • Stellen, die verbessert werden können, identifizieren • Anhand der bestehenden Tests den Code umbauenWednesday, January 23, 13
  93. 93. var fizzbuzz = function (n) { use strict; if (n % 3 === 0) { return fizz; } if (n === 5) { return buzz; } return n; };Wednesday, January 23, 13
  94. 94. greenWednesday, January 23, 13
  95. 95. REMOVE DUPLICATION • Bessere Wartbarkeit • Übersichtlicher Quellcode • Teure WeiterentwicklungWednesday, January 23, 13
  96. 96. GOLDEN MASTER • kompletter Systemtest • Generierter oder manueller Test • bei umfangreicheren Workflows sehr aufwändigWednesday, January 23, 13
  97. 97. 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); } });Wednesday, January 23, 13
  98. 98. greenWednesday, January 23, 13
  99. 99. UND JETZT? • Nimm teil an einem Coding Dojo • Führe Coding Katas durch • Pair Programming • Austausch mit anderen EntwicklernWednesday, January 23, 13
  100. 100. 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 TestsWednesday, January 23, 13
  101. 101. Fragen?Wednesday, January 23, 13
  102. 102. VIELEN DANK! Sebastian Springer Mayflower GmbH Mannhardtstr. 6 80538 München Deutschland @basti_springer https://github.com/sspringer82Wednesday, January 23, 13

×