@ivanpaulovich Stockholm, 2020 Oct 20th Testing Strategies Ivan Paulovich 

@ivanpaulovich 

@ivanpaulovich What’s TDD? A practice to use tests to guide the software implementation. Boosts the con f i dence to change and to deploy software. Works as a team communication technique. 

http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd @ivanpaulovich The Rules of TDD 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is suf f i cient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is suf f i cient to pass the one failing unit test. 

Red-Green-Refactor Red Gren Refactor Write just enough code to pass the test Improve the code without changing its behaviour Write a test and watch it fail TDD Cycle @ivanpaulovich 

–A regular developer “I technically know what I am allowed to do but I have no clue what I should do.” @ivanpaulovich 

@ivanpaulovich Testing Pitfalls Rigid tests tight coupled to the modules structure. Slow tests. Repetitive tests. Tests fail due to side effects. Testing the wrong things with the wrong approach. 

Tests @ivanpaulovich Production Code Software Artifacts Used by customers. Adds value to the product. 
 
 Used by developers. Product value is hidden under “Quality Assurance”. 

Modular Software Start of the Project Dependencies 
 Added Bugs @ivanpaulovich Big Ball of Mud 

Services Controllers Repositories Use Cases Domain External APIS Database Single Page Application HTTP TCP HTTP The Typical Software Structure @ivanpaulovich 

A Wallet Application Deposit Withdraw Transfer Close Account Open Account Database Persistence Exchange Service User Interface Exchange Rates API In Memory SQL In Memory Security @ivanpaulovich 

A Wallet Application Deposit Withdraw Transfer Close Account Open Account Database Persistence Exchange Service User Interface Exchange Rates API In Memory SQL In Memory Security @ivanpaulovich Testing a Use Case? 

A Wallet Application Deposit Withdraw Transfer Close Account Open Account Database Persistence Exchange Service User Interface Exchange Rates API In Memory SQL In Memory Security @ivanpaulovich Testing a Dependency? 

Services Controllers Repositories Use Cases Domain Unit Tets Fake API Fake DB Unit Tests @ivanpaulovich 

Unit Tests Even though an engineer could write tests for every single class in the project, it is not desirable that tests mimic the software structure. Unit Tests should run fast and in memory. Should not use I/O. Unit Tests are tight coupled to software behaviour. @ivanpaulovich 

@ivanpaulovich 

Services Controllers Repositories Use Cases Domain External APIS Database TCP HTTP Integration Tests Integration Tests @ivanpaulovich 

Integration Tests Integration tests do not mean “test the whole software integrated.” Test each single dependency isolated. It is an expensive solution to test the “database” by calling the “user interface”. @ivanpaulovich 

@ivanpaulovich 

Services Controllers Repositories Use Cases Domain External APIS Database Component 
 Tests HTTP TCP HTTP Component Tests @ivanpaulovich 

Component Tests Tests that check if the modules were wired correctly. Should not make extensive I/O. External dependencies are mocked out. @ivanpaulovich 

@ivanpaulovich 

Application External APIS Database End to End 
 Tests HTTP TCP HTTP End to End Tests @ivanpaulovich 

End to End Tests High usage of I/O. Checks if the real adapters and modules are wired up. Tests should be simpli f i ed for the happy path. Expensive to write and hard to create a variety of cases. @ivanpaulovich 

@ivanpaulovich 

What should I test first? Test Kind Criteria Unit Tests Use cases are complicated and requires clari f i cation. Integration Tests Protocols are critical and complex. Component Tests API Contracts needs to be designed and shared. End To End Tests “Never”. 

Tests Writing Considerations Think about assertion. It should be short. Each test has a single “System Under Test”. Mocks are less valuable than fakes since only fakes could run in production. 

Common Misconceptions Test-First does not mean “Write the complete test then write the code.” Test-First means “Write a little bit of the test then write a pice of the production code.” 

Hey engineer, listen to what the tests are saying… @ivanpaulovich 

1.If test setups are too long. 2.If there are too many assertions. 3.If testing is hard or too slow. Review the code and refactor. @ivanpaulovich