Unlearn Unit Testing

According to wiki, unit tests are automated tests created and executed by software engineers to make sure a part of an application conforms to design specifications and functions as intended. Even though writing looks very simple, there are many issues that come up in practice. Usually, when we try to maximize code coverage, all we end up with are time-consuming, fragile, useless test files. We keep refactoring unit tests without actually gaining anything for the codebase. What if I said that one of the most poorly understood things we perform as developers is unit testing? I'll explain what unit testing actually entails, how it affects TDD, and how to create non-brittle unit tests in this session.

Transcript

1. UNLEARN UNIT TESTING WHY MOST UNIT TESTING IS WASTE lemi orhan ergin co-founder, craftgate STOP WHAT YOU ARE DOING CHANGE YOUR MIND !
2. This talk is mainly for 
 the ones who write tests 
 but feel something wrong 
 with the written tests, and the way we do testing
3. The biggest threat for software is being rot in time due to unmanaged dependencies almost all principles and design patterns aim to decrease coupling and increase cohesion
4. Source code is the real software design. Designing software is an exercise in managing complexity. What is Software Design? The C++ Journal Vol. 2, No. 2. 1992 http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf Reference: Jack W. Reeves Author of the "(B)leading Edge" column for the publication C++ Report “
5. The software design is not complete until it has been coded and tested. Testing is part of the process of 
 refining the design. What is Software Design? The C++ Journal Vol. 2, No. 2. 1992 http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf Reference: Jack W. Reeves Author of the "(B)leading Edge" column for the publication C++ Report “
6. If someone says "this code is hard to test", it means "your design simply sucks" His Talk at Devoxx Poland https://www.youtube.com/watch?v=pnRAnP8MgBc Reference: Venkat Subramaniam Programmer, Author, Speaker, Founder Agile Developer “
7. functional acceptance testing regression testing prototypes, wireframes simulations exploratory testing a/b testing usage analytics user acceptance testing alpha / beta unit testing & tdd integration testing api compatibility via contract testing testing non-functional properties performance testing load testing security/penetration testing static code analysis checking quality attributes BUSINESS FACING TECHNOLOGY/IMPLEMENTATION FACING concept de fi ned by Brian Marick and revised by 
 Lisa Crispin & 
 Janet Gregory SUPPORT THE TEAM pass/fail con fi rmation checking for expected outputs preventing defects CRITIQUE THE PRODUCT driven by data analysis and investigation analyzing unde fi ned, unknown and unexpected fi nding defects TESTING QUADRANTS manual manual& AUTOMATED AUTomated DID WE BUILD THE RIGHT THING? DID WE BUILD IT RIGHT? HOW CAN I BREAK THE SYSTEM? CAN THE SYSTEM SCALE? AUTOMATED via special tools before/while coding post coding
8. unit testing and integration testing
9. unit testing and integration testing are totally misunderstood concepts concepts are so simple that no one even think about it, but feel it in their hearts
10. There are two types of unit tests cement unit tests: it makes the source code as hard as concrete and impossible to be refactored behavioral unit tests: the other one enabling TDD and validating behaviors easily
11. unit tests are automated tests for testing individual elements of code fast in an isolated and highly targeted way
12. unit tests are automated tests for testing individual elements of code fast in an isolated and highly targeted way Misconception Alert: Accepted by the majority, but misleading
13. Due to the misunderstanding of unit tests 
 we face with the inevitable we focus on implementation details of the code we massively use mocking for isolating the units, i.e. methods we don’t write tests when the production code is not stable we skip tests while building since fixing it requires too much work we write tests after production code to verify if its working or not we believe in the importance of high test coverage Misconception Alert: Accepted by the majority, but misleading
14. mock returns another mock Setup Exercise verify
15. 103 lines in one test 1 line for calling actual method 2 assertions 1 line for verification %95 of method is for mock setup
16. Due to the misunderstanding of unit tests 
 we face with the inevitable Misconception Alert: Accepted by the majority, but misleading unit tests makes the codebase as hard as concrete
17. Due to the misunderstanding of unit tests 
 we face with the inevitable it is usually too expensive and time consuming that makes no real advantages exist Misconception Alert: Accepted by the majority, but misleading we say it’s impossible to write unit tests in this legacy code
18. integration tests are automated tests for testing group of components against real external libraries, services and data
19. integration tests are automated tests for testing group of components against real external libraries, services and data Misconception Alert: Accepted by the majority, but misleading
20. Misconception Alert: Accepted by the majority, but misleading Due to the misunderstanding of integration tests, we face with the inevitable we focus on functionality of the requirement we massively use dependency injection for connecting components we boot up database etc. and that makes it too slow overall we write tests to verify if functionality is working or not we create tests after coding the functionality is completed
21. Misconception Alert: Accepted by the majority, but misleading Due to the misunderstanding of integration tests, we face with the inevitable integration tests are enough, no need expensive unit tests we say
23. MOST UNIT TESTS ARE TOTALLY WASTE REMOVING MORE VALUE THAN ADDING
24. LET’S UNLEARN WHAT YOU’VE LEARNED SO FAR AND FOCUS ON WHAT EFFICIENT UNIT TESTING REALLY MEANS
25. a user story is an explanation of a feature written from the perspective of the end-user needs A user can post 
 resumes 
 to the web site it ideally! includes all conversations, ideas, decisions, meeting notes and the acceptance criteria PREREQUSITE INFORMATION
26. PREREQUSITE INFORMATION user stories focus on what the user needs instead of what the system should deliver it’s not the brick in the wall (i.e. the software)
27. a use case describes the step by step process a user goes through to complete that goal using a software system. it is the system’s behavior when interacting with a user a user story can be converted into multiple use cases use cases are transformed into algorithms PREREQUSITE INFORMATION
28. PREREQUSITE INFORMATION use case defines the system behaviors and it is a brick in the wall (i.e. the software)
29. bounded contexts define the shape of the software solving specific domain problems, regardless of your team’s size and your imagination about which microservices you should have we split the domain into contexts, not microservices transactions happen inside, messages transfer between contexts PREREQUSITE INFORMATION
30. source code having two actors and multiple features accessing kafka, elastic search, redis, database and an external web service
31. bounded context contains business logic no mutations on shared states data with behaviors
32. For every implementation, a contract is defined that leads us to create fake implementation for efficient testing
33. Separate the domain logic to another build root from technology specific integration code to distinguish modules
34. unit is the behavior, testing a use case no need for a mocking framework all business logic can be tested by unit tests
35. unit tests are automated tests for testing individual behaviors fast by focusing on contracts in isolation fake implementations for building the feature 
 before deciding the technology and as using it 
 like a test double
36. unit tests are automated tests for testing individual behaviors fast by focusing on contracts in isolation where you enter the system and start the process EXIT EXIT EXIT ENTRY the behavior or the results you get at the end, 
 either returns a value, or changes a system state, or calls a third party system you should write a test for each exit point Reference: The Art of Unit Testing, 3rd Edition, Roy Osherove https://www.artofunittesting.com/
37. unit tests are automated tests for testing individual behaviors fast by focusing on contracts in isolation fake it till you make it is the heart of TDD, tests can drive design easier when you postpone technology decisions and integration code
38. integration tests are automated tests for testing the points where the system under test interacts with an external system we call implementations of the integration points as adapters in ports & adapters terminology
39. Two bounded contexts demand report 
 generate report and
40. Key Principles Unit tests should validate behaviors Write unit tests validating internals for validating algorithms Business flows should be tested very fast Integration tests should validate interaction points with technologies No need to use a mocking framework at all Mock only shared state Tests interact with contracts, handle like a black box Tests should not change by refactoring the implementation details Functional tests validate the functionality from outside Code coverage means nothing more than a report
41. https://github.com/AlicanAkkus/Modular- Architecture-Hexagonal-Demo-Project ali can akkuş software crafter craftgate lemi orhan ergin co-founder craftgate code samples: improved version 
 with DDD will be 
 available soon
42. Programming Paradigms Code Smells in OOP Stroustrup’s School of OOP Alan Kay’s School of OOP Message Passing in Practice Misconceptions about OO SOLID Actually Means Single Responsibility Principle Open Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle 1 2 Test Double and Usages Mocking Anti-Pa tt erns When Mocking Sucks Writing Mock-Free Code Unit Testing Best Practices Test Doubles and Modularity 3 Current state of unit tests Why most unit tests are waste Two types of unit tests Bonded contexts, ports & adapters Testing the behavior Design easier with TDD What is so ft ware quality How quality assurance fits Steps to increase quality Keeping the design testable Customer service impact 4 5 6
43. THANK YOU FOR SHARING YOUR TIME WITH ME speakerdeck.com/lemiorhan twitter.com/lemiorhan lemi orhan ergin co-founder, craftgate mail: lemi@craftgate.io