Embed Size (px)
Citation preview
1
Herzlich willkommen – DevDay Zürich 2016Evolutionäres Softwaredesign mit Test Driven Development
David Tanzer
#@!*§&~#%Ich wollte doch nur eine Zeile Programmcode ändern…
Jetzt sind 50 Tests rot!
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/
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
Evil tests create a lock on how the code is implemented.http://www.makinggoodsoftware.com/2012/01/27/the-evil-unit-test/
I think TDD is more like Othello: "A minute to learn. A lifetime to master."Jon Reid https://twitter.com/qcodinghttps://twitter.com/qcoding/status/433676850007506945https://de.wikipedia.org/wiki/Othello_(Spiel)
#@!*§&~#%Ich wollte doch nur eine Zeile Programmcode ändern…
Jetzt sind 50 Tests rot!
Heute:
David Tanzer (@dtanzer)[email protected]
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ückzugewinnenhttp://davidtanzer.net
Architektur / Design
Could possibly work!
Do the simplest thing that…
https://de.wikipedia.org/wiki/Basilika_Sonntagberg#/media/File:Wallfahrtsbasilika_zur_Hl._Dreifaltigkeit,_Luftbild.JPG
Arcomonte26 CC BY-SA 3.0 at
Komponenten und Modularität
Microservices
If you can't build a monolith, what makes you think microservices are the answer?Simon Brownhttp://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html
Some Design Upfront
Evil Unit Tests
Tests die…
• Eine bestimmte Implementierung voraussetzen• Duplikation verursachen• “Zufällig” rot warden• Schwer lesbar sind• Sich überschneiden• Zu viel gleichzeitig testen
The First RuleOf Simple Design
Passes its Tests!Design that is simple…
Test Driven Development
Wo sind Design / Architektur?
Testbare Designs
Designprinzipien
• The Four Rules of Simple Design• S.O.L.I.D• Coupling / Cohesion• IoC / Dependency Injection• DDD
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.”
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.“
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.“
2 Seiten einerSchnittstelle
Test Doubles
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
Test Doubles
• Mischformen möglich• Mit oder ohne Mocking Framework
Mock Objekte
Inside-Outvs.
Outside-In
Unit Testvs.
Integrated Test
UnabhängigeTests
@Testpublic void returnsAddressWithValidStreetWhenUserIsValid() {
User validUser = stubValidUser(…);Address address = addressService.addressFor(validUser);assertNotNull(address.getStreet());
}
@Testpublic void returnsAddressWithValidStreetWhenUserIsValid() {
User validUser = stubValidUser(…);Address address = addressService.addressFor(validUser);assumeNotNull(address);assertNotNull(address.getStreet());
}
Architektur-Themen
Architekturthemen
• Security• Memory / Storage Performance• Throughput• Latency• Resilience
Automatisiert Testen!
Und Jetzt?
Agile Acceptance Testing
Agile Acceptance Testing
• Features durch ihre Akzeptanzkriterien spezifizieren• Akzeptanzkriterien so schreiben, dass sie automatisch
Akzteptanztests ergeben• Akzeptanztests automatisieren
[email protected] 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ückzugewinnenhttp://davidtanzer.net
