5 Tips to Upgrade Code Quality Using Automation Testing

As a software engineer, I get often asked for advice on how to upgrade code quality. The answer is that automation testing has the ability to upgrade code quality and improve overall testing experience, when being implemented at particular occasions. After years of working on projects in software testing, I want to share the 5 best occasions to start the process of writing automated tests, to transform the quality of your code from good to exceptional:

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:

• Login
• Create new document
• Logout

Another test would be:

• Login
• Create new document
• Logout
• 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:

• Readability– the focus should be on test readability because they can be maintained by any developer working on the system. If there are multiple people involved, some might be less proficient using the End 2 End testing framework, yet must be able to effectively triage a failed test, update an existing one or write a test for a new feature. A good example: asynchronous JavaScript tests that use async/await feature are easier to read for people unfamiliar with JavaScript than tests using promises, so pick your test automation framework wisely.
• 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 😉

---

Reference

---