DEV Community

Cover image for Unit testing: Why do I write them?
Mariam Reba Alexander
Mariam Reba Alexander

Posted on

4 2

Unit testing: Why do I write them?

Many companies today want developers with unit testing experience. Even though unit testing had existed for decades, some developers still don’t know how to write them.

When I started coding as a self-taught developer, I didn’t come across unit testing, and later when I started to work with other developers, I heard few mentions. That’s when I started checking what it’s all about.

Once I began writing unit tests I started to see the benefits. One of the things that I like about it is that I can detect any bugs early on during the development.
My tests start failing for the method or function if there is a bug. From the warning and error logs of the test, I can determine what went wrong and help me to fix it before I commit the code. Unit tests have increased the confidence in my code and this resulted in less number of defects getting shipped into production.

Later I faced another problem. I was told to target a certain percentage of test coverage on all the lines of code. So I started focussing on fulfilling the requirement and found that the number of tests was increasing. I was writing tests just to cover the lines of code even for the lines that were too silly to test. I also found ways to manipulate test coverage results. Another issue was that the tests were getting complex as it was interdependent on other libraries or external files in the project. I saw that some of my tests were affecting the results of other tests. When a simple logic was updated the whole test suite failed. It became unmanageable.

This could be the story of some developers and at this point, they would start hating unit tests and feel that it is a total waste of time writing and maintaining them.

The problem lies in the way one writes unit tests. I realized it the hard way.

So here is how I approach it now.

  1. Test one behavior at a time.
  2. Use test doubles (mock) for external dependencies, so that the focus is on testing the function's behavior alone.
  3. Test in isolation, ie there should be no relation between tests, it should be able to run independently and give the same result as compared to running the whole test suite.
  4. Focus on testing the output rather than on the implementation details.
  5. Test all conditions, i.e all if and else conditions, and with variants of inputs.
  6. For discoverability write tests in the order in which it appears in the code and scope multiple tests of the same function in a block.
  7. Write good test descriptions, as you have to read them later.

Keeping the above points in mind helped me write clean tests and avoid false positive results.

There may be a different approach that you follow that helped you manage tests. If so share it in the comments.

In the next part of the series, I would like to take you through some good and bad test code examples in Javascript unit testing.

Image of Timescale

🚀 pgai Vectorizer: SQLAlchemy and LiteLLM Make Vector Search Simple

We built pgai Vectorizer to simplify embedding management for AI applications—without needing a separate database or complex infrastructure. Since launch, developers have created over 3,000 vectorizers on Timescale Cloud, with many more self-hosted.

Read full post →

Top comments (0)

Image of Docusign

🛠️ Bring your solution into Docusign. Reach over 1.6M customers.

Docusign is now extensible. Overcome challenges with disconnected products and inaccessible data by bringing your solutions into Docusign and publishing to 1.6M customers in the App Center.

Learn more

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay