Unit Testing… Please?

This article will try to address the need for Unit Testing and will help you overcome the inertia, “Why Unit Testing?”

Types of Inertias against Unit Testing

1. Unit Testing? How does it help?
2. I don’t have time for Unit Testing
3. I already have a lot of functional tests that would cover all the scenarios!
4. My app already has more than enough coverage set by my Organization... let me skip Unit Testing for this feature!
5. I am not a QA to write Tests!

Who is this article for?

If you have any one or more of the inertias that are mentioned above, this article is for you.

Inertia 1: Unit Testing? How does it help?

A well-written unit test would try and address the following intents.

1. Does my function address my business logic? This involves testing the happy path of your function to ensure that it is behaving as it should under ideal circumstances.
2. How would my function behave during an edge case? This is the intent that would make your function resilient to whatever you throw at it. For example, it’s OK for your function to throw a NullPointerException or handle it internally based on your dev/team/org’s standards. But make it a practice to assert the behavior consciously.
3. Is my function’s behavior consciously endorsed and guarded against accidental maintenance changes? This will usually be a byproduct of #1 and #2. When someone accidentally changes the behavior, the build would fail and let the developer know that there is a delta between the old and existing business logic. Time to re-assert the modification consciously or engage your product manager for more clarity on the business logic!
4. It is cheap and will help us fail fast. Recovery from a unit testing failure is usually faster than finding a failure during the later stages of the life cycle. This saves a lot of resources for the company. Please be mindful that developer’s time is one of the most expensive resources that a company would pay for. For example, having a check against a simple “undefined” access on a web application could prevent a page load failure or a high priority incident. Imagine a retailer’s broken checkout page because the “analytics” variable in JavaScript was “undefined”.

Image Citation: https://martinfowler.com/bliki/TestPyramid.html

Inertia 2: I don’t have time for Unit Testing

This is one of the most common reasons among developers who hesitate to write unit tests. The “Viability” in MVP (Minimum Viable Product), for sure, does not indicate compromising on test cases. Moreover, I would ask the time-constrained developer, the following questions.

1. What is preventing you from providing a realistic estimate of a feature by taking unit testing into consideration?
2. There could be genuinely time sensitive features where time to market precedes a few probable minor bugs that could be prevented by Unit Testing. But what is preventing you from adding a task in your backlog to add unit test coverage for the feature?

After all, you will soon find out that unit testing smaller functions thoroughly is not as time-consuming as you thought.

Inertia 3: I already have a lot of functional testing that would cover all the scenarios!

If you already have a strong functional suite, Kudos! But remember the 4th point under Inertia 1? Unit Testing is cheap and fast. Let’s take a look at the following example.

Bob, who is now developing “FeatureX” for their web application, is enthralled by the beauty of Selenium tests and decides to focus more on the end-to-end integration tests than unit tests.

He spends many days writing integration tests for multiple business scenarios. When it’s finally time to deliver his feature, he gladly pushes the trigger with enough confidence in his Integration test coverage. His build though fails in the Integration environment due to an unintended dependency, an unstable ad-services application.

Let’s wish him good luck in reproducing all the edge cases in the integration environment manually! He could have written far more unit tests in a far lesser time covering all the edge case scenarios and could have only tested the happy path functionality manually. See the maintenance involved as we move through later testing stages?

Inertia 4: My app already has more than enough test coverage set by my Organization... let me skip Unit Testing for this feature!

We got to realize that testing coverage thresholds set by an Organization are a way to force developers to write "at least" a bare minimum number of tests so that the number of production bugs could be mitigated. Having a high enough coverage indicates that developers who worked on the code base earlier focused on the quality of the product and was not willing to compromise. Your new feature not having unit tests will not only pull the coverage down but will also make the product/feature prone to bugs that will only be found in the later stages making them costlier.

Inertia 5: I am not a QA to write Tests!

In my opinion, this is a concerning thought process. Quality should not be limited to QAs. Testing is a collective responsibility that will make your product and organization more appealing to your customers. It will make any developer a “quality” developer.

If not by testing, how else will you scientifically prove that your code produces the same result every single time and new changes have not caused any regressive failures?

Happy quality development!