UNLEARN UNIT TESTING WHY MOST UNIT TESTING IS WASTE lemi orhan ergin co-founder, craftgate STOP WHAT YOU ARE DOING CHANGE YOUR MIND !

This talk is mainly for 
 the ones who write tests 
 but feel something wrong 
 with the written tests, and the way we do testing

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

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 “

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 “

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 “

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

unit testing and integration testing

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

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

unit tests are automated tests for testing individual elements of code fast in an isolated and highly targeted way

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

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

mock returns another mock Setup Exercise verify

103 lines in one test 1 line for calling actual method 2 assertions 1 line for verification %95 of method is for mock setup

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

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

integration tests are automated tests for testing group of components against real external libraries, services and data

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

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

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

No content

MOST UNIT TESTS ARE TOTALLY WASTE REMOVING MORE VALUE THAN ADDING

LET’S UNLEARN WHAT YOU’VE LEARNED SO FAR AND FOCUS ON WHAT EFFICIENT UNIT TESTING REALLY MEANS

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

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)

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

PREREQUSITE INFORMATION use case defines the system behaviors and it is a brick in the wall (i.e. the software)

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

source code having two actors and multiple features accessing kafka, elastic search, redis, database and an external web service

bounded context contains business logic no mutations on shared states data with behaviors

For every implementation, a contract is defined that leads us to create fake implementation for efficient testing

Separate the domain logic to another build root from technology specific integration code to distinguish modules

unit is the behavior, testing a use case no need for a mocking framework all business logic can be tested by unit tests

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

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/

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

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

Two bounded contexts demand report 
 generate report and

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

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

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

THANK YOU FOR SHARING YOUR TIME WITH ME speakerdeck.com/lemiorhan twitter.com/lemiorhan lemi orhan ergin co-founder, craftgate mail: [email protected]