1. Before Writing Code
I love writing tests, unfortunately it takes a long time to complete their writing. Instead of spending such a long time on writing tests after completing writing the software, when I code a clearly defined small algorithm (such as sorting), I start with writing the tests. The tests help me to understand the problem and ensure I don’t get outside of the scope. This is the classic TDD (Test Driven Development) approach, while unit testing frameworks with watch mode are very helpful for this.
2. When Writing Documentation
I like reading little code examples showing how functions work. It might be just me, but I understand the code example faster than the text.
Since the documentation gets out of sync with the code really quickly, it is important to have tested examples in your documentation. Tools like xplain and comment-value are my solutions to this problem. They ensure the documentation is accurate, yet require few unit tests. Usually, these tests show the most user friendly cases which are great for learning about the code functions.
3. Functional Test Writing (End 2 end) After System Deployment
When a complete system has been assembled from smaller modules (I really like the Twelve-factor app architecture) and deployed, I write simple “success path” functional tests that simulate a typical user. A typical functional test would include:
- Create new document
Another test would be:
- Create new document
- Login again
- Find previously created document
The tests are really the “use case scenarios” and describe the system’s behavior when things are well. There are two requirements at this stage:
- The test failure should have all the information for triage: logs, screenshots, stack, linked crash reports, etc. Otherwise, it can be hard to recreate a specific environment and conditions to repeat the failure in a complex system.
4. Right After Bug Report
If a user of my library, API or website finds a bug, I write a test first, before working on a fix.
- The test should recreate the failure, which is often hard to do manually.
- I insert the bug ID in the test name to easily find it.
- The test prevents regressions in the future.
5. Before Code Refactoring
In case I decide to perform code refactoring, even if it has unit tests, I usually write a few tests to clarify the behavior. This allows me to remember how the code works, fill missing edge cases and ensure I do not accidentally break an existing contract. Test redundancy is a problem in this case, a solution for it will be using code coverage tools to avoid it.
-These are the 5 best occasions to consider writing tests to upgrade code quality. In which occasions do you recommend writing automated tests? Please share why 😉