How to Improve Unit Testing Scripts

Photo by Super Snapper on Unsplash

It’s always been thought that code coverage is a measurement of code quality, no matter what programming language you are using. But, is this true? After years of writing tests as a developer, I think a good testing script should be relatable, readable, and maintainable in the long run. Testing script should not be a graveyard for developers only wanting to rush out and prioritise the code coverage score.

Before beginning your story structure, write it down. Do this before any testing. More importantly, the test structure layout should be relatable. When others read it they should know how it begins, proceeds, and ends. A bad test structure will be written like an unrelatable robot language: giving A it will show B, with B it will become C.

vscode testing structure, bad example by Jun Kit

To improve the structure, the user journey should be the key point or main character in the layout. For example, when a user enters his/her name with an enter-key at the end, an alert message will be shown up mentioning “Registration is done”. However, if the name is found on the existing database an alert “Duplicated entry is found” will pop-up.

vscode testing structure, good example by Jun Kit

Details are important but sometimes if the sentence is too long it’s difficult to read, especially on a narrow screen. So grouping is a good approach to organise the structure more effectively.

vscode testing structure, better example by Jun Kit

With grouping, the code readability will be improved and makes the next developer or QA much easier to maintain if you are not working in the company anymore.

I am still on the learning journey when it comes to writing better test scripts, and sometimes I forget how important the user journey is in testing scripts.

Achieving 100% coverage with an unmaintainable test code will not be possible when a change request comes in, because you won’t know how to correct it. It creates a lot of worries and nervousness when removing tests you don’t know.

The answer is to write a better structure before jumping into the actual testing script. Build the structure before building the house.

I’d love to know what you think, so feel free to add some comments.