Unit Testing and Test Driven Development

We have seen varied definitions of unit testing and also a list of frameworks that are adopted in the industry to make things easier for all stakeholders by making the system more testable, easy to fix and at the same time to make the whole process faster.

I am going to discuss here my own experiences with unit testing and the never-ending process of improving the test cases and making sure that the test coverage for your system is 100 percent or the best possible figure.

Why Unit Test? What does it mean to write a Unit Test?

Unit testing is one form of testing among many other types of testing done on the system, each of them has their own purpose.

The purpose of unit testing is to test units of source code to determine whether they are fit for use, a single unit of code is the smallest testable code possible selected, so that, it is easier to design, execute, record, and analyze test results than larger chunks of code.

Usually, this is not followed to a large extent in the industry and the developers tend to test a large method or function in a single unit test case. That is undesirable, and also it is not solving the purpose of doing a unit test.It becomes difficult to identify and fix the code when unit test cases are not written in a way they should be.

To add more, to write a unit test case, it is consequential to test a single smallest piece of code in different ways.

Like, for instance, we need to write a test case for a method that returns to Boolean value and takes in some parameters.

What do you think? A single unit test case is enough in this case? No, it is not, this is again a serious issue the industry faces as a large percentage of developers do not follow this. We need the following test cases for it.

1. Pass the parameters which you know returns true and assert.

2. Pass the parameters which you know will return false and assert.

3. Test for an exception, if it is caught or not.

This seems tiring to write so many test cases for such a small function, but, it significantly help improve the time required to pinpoint an error when something goes wrong with the system and not to forget; increasing observability, testability, modifiability and reducing costs.

Experiencing TDD:

I was a strong advocate of TDD as it has its own benefits, I should say a lot of benefits. I would say that TDD is more of a code design methodology than a testing methodology. You write the test case and start developing the code to pass the test case you have written, it really helps you to write code that is to the point, nothing less – nothing more than the requirements.

Why I am no more strongly advocate TDD?

A lot of developers would not agree with me, but, let me tell you the reasons.

1. It is good as a training tool to write quality code, so useful for new developers.

2. Introduces a lot of code to achieve the results viz., mocks, dependencies, using IOC. Are we going to write test cases to test the test cases? :)

Primarily, because of these reasons, I would say that though TDD has its benefits it should be mostly used by new programmers to write quality code.

While the seasoned developers should be a little more pragmatic to use it whenever it is required and not all the time.