Five approaches to testing

There are many different reasons to test.

Unit testing allows us to plug into and execute our code without the application running.

It is an incredible tool to be able to handle. It can really speed things up.

See bundled github project for exercises and examples:
https://github.com/ddikman/five-ways-to-test

Transcript

1. Five approaches to testing How to and when to
2. Overview - Why we do unit testing - The five approaches - Test Driven Development - Learning - Coverage - After-the-fact - Just don’t - Conclusion
3. Why we do testing 01 To enable refactoring No tests > Fear of change > Exponential code rot 02 To prove functionality Test > Coverage > Increased confidence it works Unit (and other automated) tests. Find faults faster, speeds up 03 To document Test = This is how it should work
4. Test driven development Red-Green-Refactor cycle 1. Write one single tiny test > run > fails 2. Write minimal code to make it pass > run > green 3. Improve (refactor) code to make it cleaner > run > green Suitable when: I know what I need to do. I know how to do it. I want to do it right
5. Example. Step 1 write test
6. Example. Step 2 make it pass
7. Example. Step 3 refactor, still passing
8. Example. Step 4 write the next test
9. Learning Similar to TDD. 1. Write a test to run some code 2. Debug or print outputs 3. Explore and learn 4. Rewrite with TDD (if needed) Works well when you know what you need to do but not quite how to do it. Backdoor to running some specific code. Also good for debugging.
10. Example. Step 1 create a test file
11. Example. Step 2 write some code you want to try
12. Example. Step 3 debug through, print etc. Iterate until it works
13. Example. Step 4 clean up
14. Coverage Get confidence to change. 1. Someone’s written some code 2. You want to change it 3. Add coverage with tests 4. Change it If all tests still pass, you haven’t broken anything!
15. Example. Step 1 find some old code
16. Example. Step 2 add tests for full coverage
17. Example. Step 3 add new test for missing functionality, should fail
18. Example. Step 4 fix failing test and check coverage again
19. Example. Refactor (without changing any tests) if needed, we know everything still works
20. After-the-fact Okay, so, some times, we write code first and tests afterwards. 1. You write some code 2. Your CI tells you your coverage has dropped 3. You add tests Why do this? Two reasons: 1. Do you really need all that code? 2. To be able to safely refactor
21. Same process as with getting coverage! Only difference is, you’re not sure if your code actually works or not. So make sure you write test cases, not to test the code but to test the behaviour.
22. Example. Step 1 you’ve written some code
23. Example. Step 2 you add tests
24. Example. Step 3 you find superfluous code and faults that can be fixed
25. Example. Step 4 finally, we can check our coverage
26. Just don’t Then there are the times we just shouldn’t. Or, at least not with unit tests. Some of these are better for humans, UI test frameworks or integration tests. - Visual (texts, images, themes) - Data (default values, configuration) - SQL and API calls - UI interactions and animations
27. Conclusion There are many different reasons to test. Unit testing allows us to plug into and execute our code without the application running. It is an incredible tool to be able to handle. It can really speed things up.
28. Questions? You can find the examples on: https://github.com/greycastle/five-ways-to-test