Evolutionary Software Design with TDD

Transcript

1. Evolutionary Software Design with Test Driven Development
2. #@!*§&~#% I just wanted to change a single line of code… Now I have 20 red tests!
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. Today: • Test Driven Development • Components • Simple Design • SOLID • 2 Sides of an Interface • Outside-in vs Inside-out
9. David Tanzer (@dtanzer) business@davidtanzer.net I help my clients to: • Work together more effectively as a team • Improve their technical practices • Improve their software quality / design • Re-gain control of their legacy code http://davidtanzer.net
10. Could possibly work! Do the simplest thing that…
11. The First Rule Of Simple Design
12. Passes its Tests! Design that is simple…
13. Test Driven Development
15. Where are Design / Architecture?
16. Some Design Upfront
17. Design- / Architecture Vision Make sure it can change!
19. Components and Modularity
23. Microservices
26. 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
28. Evil Unit Tests
29. Tests that… • Rely on a certain implementation • Cause duplication • Become red from time to time / for “no reason” • Are hard to read • Overlap • Test too much at once
30. Evel unit tests will impede refactoring later!
31. Testable Designs
32. Design Principles • The Four Rules of Simple Design • S.O.L.I.D • Coupling / Cohesion • IoC / Dependency Injection • DDD
33. 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.”
36. 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.“
39. 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.“
42. 2 Sides of an Interface
44. Test Doubles
45. Test Doubles • Dummy Objekte that you pass around, but never really use. • Fake have an implementation, but are simpler than the „real“ object. • Stubs when invoked, always return canned answers. • Mocks give us a possibility to verify that they were used correctly during the test. http://martinfowler.com/articles/mocksArentStubs.html
46. Test Doubles • Multiple roles possible • With or without a mocking framework
47. Mock Objects
48. Inside-Out vs. Outside-In
57. And now?
58. Architecture provides boundaries for TDD … e.g. Simon Brown (@simonbrown) https://twitter.com/simonbrown/status/746968018861821952 The best part was implementing the software TDD-style along the Component-Diagram, that felt very natural and made total sense. Kevin Wittek (@Kiview) https://twitter.com/Kiview/status/726350299150049280
59. Have a design vision at any point in time • Make sure everyone is committed to it • Be wary if it’s still the same as one year ago
60. Make sure your tests are independent
61. Make sure your tests are small and simple So you won’t mind throwing them away if you have to
62. Make sure you test interfaces …from both sides
63. TDD is like chess: you can learn the rule in a few minutes, but if you’re lucky, you’ll learn new things from it every day. J.B. Rainsberger https://twitter.com/jbrains https://twitter.com/jbrains/status/433659281544855552
64. Thank You! business@davidtanzer.net | @dtanzer I help my clients to: • Work together more effectively as a team • Improve their technical practices • Improve their software quality / design • Re-gain control of their legacy code http://davidtanzer.net
65. Agile Acceptance Testing
66. Agile Acceptance Testing • Specify features only by defining their acceptance criteria • Write acceptance criteria in a way so that you can directly automate them as acceptance tests • Automate all testing (esp. acceptance tests)
67. Unit Test vs. Integrated Test
72. Independent Tests
73. @Test public void returnsAddressWithValidStreetWhenUserIsValid() { User validUser = stubValidUser(…); Address address = addressService.addressFor(validUser); assertNotNull(address.getStreet()); }
74. @Test public void returnsAddressWithValidStreetWhenUserIsValid() { User validUser = stubValidUser(…); Address address = addressService.addressFor(validUser); assumeNotNull(address); assertNotNull(address.getStreet()); }
75. Architectural Topcis
76. Architectural Topics • Security • Memory / Storage Performance • Throughput • Latency • Resilience Test them in an automated way!