Best Practices In Writing Unit Tests

In programming, Unit testing is a method in which individual units of our source code will be tested to make sure they are ready to use. For sure, Unit testing can significantly increase the quality of code.

Unit testing is not about finding bugs;  we should understand the motto behind the unit testing. It’s not to find bugs or detect regressions instead it is to examine our code.

Some tips for Unit testing,

1. Test only one code at a time

2. Write Independent unit tests and avoid chaining

3. Mock out all service calls and database operations.

4. Follow naming conventions for your unit test to understand what it does

5. All methods should have appropriate unit tests.

6. Don't perform multiple assertions in single test, instead write multiple unit tests.

7. Use appropriate assertion methods and mention assertion parameters in proper order.

8. Make sure that your test code should not be part of production code.

9. Don't print anything out in in unit tests.

10. Don't skip unit tests instead remove it from source code.

FIRST Principles of Good Unit Tests

Acronym FIRST stand for below test features,

1. [F]ast

2. [I]solated

3. [R]epeatable

4. [S]elf-validating

5. [T]imely

If we follow these five principles in writing unit test, we will have more stable and higher quality code.

Let's have a look into these FIRST principles in detail.

Fast

Unit tests should be fast, otherwise it will waste lot of productivity, consider we have 5000-unit test in our application and let’s say each unit test will take 300ms on average to execute, then to run all the unit tests. it will take 25 minutes to complete. 25 minutes time is not very long time at this moment, but maybe we need to run them for several times in a day to make sure everything is passing before committing the changes.

And one more thing, as time goes on the unit tests count will be increase, which may take more than this time. Hence the unit tests should be fast.

Isolated

Don't ever write unit tests which depend on other unit test cases. I strongly disagree to write unit tests which depend on each other, no matter how carefully, we design them, sometimes it may give false alarms.

The reason for this is, ideally at any time, we should able to run any one of test at any time and any order. And there must be only one reason to fail our unit test. If the unit test fails for more than one reason, then I suggest to split the unit test into multiple.

Repeatable

A repeatable test is one that gives the same output/result every time we run it. To achieve repeatable tests, we must isolate from anything in the external environment.

For this we can use mock objects to avoid external environment interaction.

Self-validating

All the unit tests should be self-validating, which means each unit test should be able to determine if the output is expected or not.

In one go, it should determine either it passed or failed. No manual interruption should be present to get the results.

I suggest you automate all the manual steps like preparing data, configurations and everything.

Timely

Unit test must be written even before the production code that makes the test pass. However, in practical scenarios, you can write your unit test at any time.

As a suggestion, we should have some guidelines around unit testing, following review processes, or having an automated tool to reject the code check-in if code is not covered by unit test are some of the techniques we follow.

I can't say by following these rules alone will make our unit tests perfect, but by following this rules our unit tests will give some improvement.

Please let me know your thoughts.

Happy Learning!!

Ebook Download
View all
Learn
View all