TDD sucks! But that has not have to be!

Christian Fischer Software Engineering Coach http://agiledojo.de @agiledojo

TDD in a Nutshell Test Implementation Refactoring

Design Evolution

Design Evolution Test make my Design hard to change. When the Design changes due to new requirements, I have to change my tests everytime.

QueryParserTest Design Evolution „guitar“ -> [guitar] “red electric guitar“ -> [red, electric, guitar] „red guitar with gigbag“ -> [red,guitar,gigback] „red guitar and gigbag“ -> [red,guitar,gigback] QueryParser + parse(String query): String[] - removeStopwords(String[] words) : String[] „red guitar with 7 gigbag“ -> [red,guitar,gigback] - removeNumbers(String[] words) : String[]

QueryFilter QueryFilterTest QueryParserTest Design Evolution „guitar“ -> [guitar] “red electric guitar“ -> [red, electric, guitar] [red,guitar,with,gigback]-> [red,guitar,gigback] [red,guitar,and,gigback] -> [red,guitar,gigback] QueryParser + parse(query: String): String [] - removeStopwords(words: String[]) : String[] [red,guitar,7,gigback] -> [red,guitar,gigback] - removeNumbers(words: String[]) : String[] + filter(words: String[]): String[] + QueryParser(filter: QueryFilter) -setUpMocks / MockInteractionTest

QueryFilter QueryFilterTest QueryParserTest Design Evolution „guitar“ -> [guitar] “red electric guitar“ -> [red, electric, guitar] [red,guitar,with,gigback]-> [red,guitar,gigback] [red,guitar,and,gigback] -> [red,guitar,gigback] QueryParser + parse(query: String) - removeStopwords(words: String[]) : String[] [red,guitar,7,gigback] -> [red,guitar,gigback] - removeNumbers(words: String[]) : String[] + filter(words: String[]): String[] + QueryParser(filter: QueryParser) -setUpMocks „Guitar“ -> [guitar] - toLowerCase(word: String) : String - toSingular(word: String) : String “guitars“ -> [guitar]

QueryFilter QueryFilterTest QueryParserTest Design Evolution „guitar“ -> [guitar] “red electric guitar“ -> [red, electric, guitar] [red,guitar,with,gigback]-> [red,guitar,gigback] [red,guitar,and,gigback] -> [red,guitar,gigback] QueryParser + parse(query: String) - removeStopwords(words: String[]) : String[] [red,guitar,7,gigback] -> [red,guitar,gigback] - removeNumbers(words: String[]) : String[] + filter(words: String[]): String[] + QueryParser(filter: QueryFilter, normalizer: QueryNormalizer) -setUpMocks / MockInteractionTest QueryNormalizerTest „Guitar“ -> „guitar“ „guitars“ -> „guitar“ QueryNormalizer + normalize(word: String): String - toLowerCase(word: String) : String - toSingular(word: String) : String

Strong Coupling Parser Module QueryParser QueryFilter QueryNormalizer QueryParserTest Parser Tests QueryFilterTest QueryNormalizerTest public Class package private Class

Loose Coupling Parser Module QueryParser QueryFilter QueryNormalizer QueryParserTest Parser Tests QueryFilterTest QueryNormalizerTest public Class package private Class

Design Evolution Develop your Tests against the Module API.

Leaky Refactoring

Leaky Refactoring When I refactor my Code, the tests fail and I have to rewrite them.

Leaky Refactoring

Leaky Refactoring Refactoring: Split name into two fields.

Leaky Refactoring Treat your implementation code as a Blackbox and only test Behaviour.

Mocking Frameworks

Mocking Frameworks I have to painfully write all these Framework Mocks.

Mocking Frameworks

Mocking Frameworks Write Adapters and mock these.

Weak Unit Tests

Weak Unit Tests I feel like I am writing code just for the sake of Code Coverage.

Weak Unit Tests Does the Endpoint has the corrrect Path & Method? Does the Deserialization works as expected? Does the Serialization works as expected?

Weak Unit Tests Don‘t write Unit Tests for I/O components. Use Integration Tests instead.

Acceptance Testing

Acceptance Testing Acceptance Tests are the new Unit Tests.

Test Fixture Order Repository setUp Data MyShop <> Order REST Controller Order Mgmt RestAssured DBUnit ShopTest send/verify Request

Acceptance Testing „Delivery Date is estimated based on delivery address.“ Fixture: Test:

Debugging Order REST Controller Time Formatting Time Calculation Order Mgmt What went wrong? Time Parsing Order Repository

Test Pyramid Order Repository setUp Data MyShop <> Order REST Controller Order Mgmt RestAssured DBUnit ShopTest send/verify Request 5 5 5 1

Test Pyramid setUp Data MyShop <> RestAssured DBUnit ShopTest send/verify Request 5*5*5=125

E2E Test Tests should have a specific scope. Number of Tests decrease with scope range.

QA Triangle Coverage Efficiency Effectiveness

5 Rules for efficient and effective TDD 1 Develop your Tests against the Module API. 2 Test the Behaviour, not the Implementation. 4 Use Integration Tests for I/O-Components. 3 Don‘t mock external libraries, use Adapters. 5 Make use of the Test Pyramid.

no Multi- Tasking Protection from Overengineering Complexity Partitioning no Fear of Change zero Debug Time Testable Design TDD Benefits TDD

Fragen?