Evolutionäres Softwaredesign mit TDD

Transcript

1. 1 Herzlich willkommen – DevDay 2016 “Evolutionäres Softwaredesign mit Test Driven Development”
2. #@!*§&~#% Ich wollte doch nur eine Zeile Programmcode ändern… Jetzt sind 50 Tests rot!
3. I have lost count of the times where I have seen a developer mock out more than they need to because of excessive class coupling in their code. https://stephenhaunts.com/2013/03/07/all-your-mocks-are-evil/
4. Sometimes the design is not clear at the start and evolves as you go along - this will force you to redo your test which will generate a big time lose. http://stackoverflow.com/questions/64333/disadvantages-of-test-driven-development
5. Evil tests create a lock on how the code is implemented. http://www.makinggoodsoftware.com/2012/01/27/the-evil-unit-test/
6. I think TDD is more like Othello: "A minute to learn. A lifetime to master." Jon Reid https://twitter.com/qcoding https://twitter.com/qcoding/status/433676850007506945 https://de.wikipedia.org/wiki/Othello_(Spiel)
7. #@!*§&~#% Ich wollte doch nur eine Zeile Programmcode ändern… Jetzt sind 50 Tests rot!
8. Heute:
9. David Tanzer (@dtanzer) business@davidtanzer.net Ich helfe meinen Kunden: • Als Teams effektiver zusammenzuarbeiten • Technische Praktiken zu verbessern • Qualität und Design ihrer Software zu verbessern • Kontrolle über ihren Legacy-Code zurückzugewinnen http://davidtanzer.net
10. Architektur / Design
13. Could possibly work! Do the simplest thing that…
15. https://de.wikipedia.org/wiki/Basilika_Sonntagberg#/media/File:Wallfahrtsbasilika_zur_Hl._Dreifaltigkeit,_Luftbild.JPG Arcomonte26 CC BY-SA 3.0 at
16. Komponenten und Modularität
20. Microservices
24. If you can't build a monolith, what makes you think microservices are the answer? Simon Brown http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html
25. Some Design Upfront
26. Evil Unit Tests
27. Tests die… • Eine bestimmte Implementierung voraussetzen • Duplikation verursachen • “Zufällig” rot warden • Schwer lesbar sind • Sich überschneiden • Zu viel gleichzeitig testen
28. The First Rule Of Simple Design
29. Passes its Tests! Design that is simple…
30. Test Driven Development
32. Wo sind Design / Architektur?
34. Testbare Designs
35. Designprinzipien • The Four Rules of Simple Design • S.O.L.I.D • Coupling / Cohesion • IoC / Dependency Injection • DDD
36. Single Responsibility Principle “Every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.“ “A class should have only one reason to change.”
39. Dependency Inversion Principle “High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.“ “Your business logic should not depend on your infrastructure code.“
42. Interface Segregation Principle “No client should be forced to depend on methods it does not use.“ “The consumer defines what it needs from an interface. Every consumer gets their own interface.“
45. 2 Seiten einer Schnittstelle
47. Test Doubles
48. Test Doubles • Dummy Objekte werden weitergegeben, aber nie verwendet. • Fake haben eine einfachere Implementierung als das echte Objekt. • Stubs liefern vorgefertigte Rückgabewerte. • Mocks geben uns die Möglichkeit, zu überprüfen, ob sie im Test richtig verwendet wurden. http://martinfowler.com/articles/mocksArentStubs.html
49. Test Doubles • Mischformen möglich • Mit oder ohne Mocking Framework
50. Mock Objekte
51. Inside-Out vs. Outside-In
60. Unit Test vs. Integrated Test
65. Unabhängige Tests
66. @Test public void returnsAddressWithValidStreetWhenUserIsValid() { User validUser = stubValidUser(…); Address address = addressService.addressFor(validUser); assertNotNull(address.getStreet()); }
67. @Test public void returnsAddressWithValidStreetWhenUserIsValid() { User validUser = stubValidUser(…); Address address = addressService.addressFor(validUser); assumeNotNull(address); assertNotNull(address.getStreet()); }
68. Architektur- Themen
69. Architekturthemen • Security • Memory / Storage Performance • Throughput • Latency • Resilience Automatisiert Testen!
70. Und Jetzt?
73. Agile Acceptance Testing
74. Agile Acceptance Testing • Features durch ihre Akzeptanzkriterien spezifizieren • Akzeptanzkriterien so schreiben, dass sie automatisch Akzteptanztests ergeben • Akzeptanztests automatisieren
75. Danke! business@davidtanzer.net Ich helfe meinen Kunden: • Als Teams effektiver zusammenzuarbeiten • Technische Praktiken zu verbessern • Qualität und Design ihrer Software zu verbessern • Kontrolle über ihren Legacy-Code zurückzugewinnen http://davidtanzer.net