Testing Strategies - Nordkap

https://www.youtube.com/watch?v=daStZZo5Zew

Transcript

1. @ivanpaulovich Stockholm, 2020 Oct 20th Testing Strategies Ivan Paulovich
2. @ivanpaulovich
3. @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.
4. 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.
5. 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
6. –A regular developer “I technically know what I am allowed to do but I have no clue what I should do.” @ivanpaulovich
7. @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.
8. Tests @ivanpaulovich Production Code Software Artifacts Used by customers. Adds value to the product. 
 
 Used by developers. Product value is hidden under “Quality Assurance”.
9. Modular Software Start of the Project Dependencies 
 Added Bugs @ivanpaulovich Big Ball of Mud
10. Services Controllers Repositories Use Cases Domain External APIS Database Single Page Application HTTP TCP HTTP The Typical Software Structure @ivanpaulovich
11. 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
12. 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?
13. 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?
14. Services Controllers Repositories Use Cases Domain Unit Tets Fake API Fake DB Unit Tests @ivanpaulovich
15. 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
16. @ivanpaulovich
17. Services Controllers Repositories Use Cases Domain External APIS Database TCP HTTP Integration Tests Integration Tests @ivanpaulovich
18. 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
19. @ivanpaulovich
20. Services Controllers Repositories Use Cases Domain External APIS Database Component 
 Tests HTTP TCP HTTP Component Tests @ivanpaulovich
21. Component Tests Tests that check if the modules were wired correctly. Should not make extensive I/O. External dependencies are mocked out. @ivanpaulovich
22. @ivanpaulovich
23. Application External APIS Database End to End 
 Tests HTTP TCP HTTP End to End Tests @ivanpaulovich
24. 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
25. @ivanpaulovich
26. 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”.
27. 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.
28. 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.”
29. Hey engineer, listen to what the tests are saying… @ivanpaulovich
30. 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