An afternoon tea with Unit Testing


What the heck is Unit Testing?

To talk my mind, I would say Unit testing is the process where you try to test the smallest indivisible unit or function that your write inside a class file.

However don't take my word as is and see the official statement about this topic cited below.

Source: Wikipedia(1)

Unit tests are typically automated tests written and run by software developers to ensure that a section of an application (known as the "unit") meets its design and behaves as intended. In object-oriented programming, a unit is often an entire class, but could be an individual method.

Source: Microsoft's MSDN Blog(2)

Unit testing is testing directly at the most granular level.

Hold on a minute!

What can we test in unit testing? There is a subtlety when it comes to understand unit testing and its other counterparts in testing. I will devise a difference between unit testing and integration testing to clear that out.

Unit Testing

  • Ideally, A unit test deals with testing of code without external dependency
  • External dependencies like accessing a file, referring to 3rd party dlls , reading database etc

  • But, in real world scenario, we often come across n-tier application which has layers dealing with accessing data from outer source, reading file, other external dlls etc.
    To overcome this issue we often create Mocks and then the unit test becomes interaction test

Integration Testing

  • Integration and other higher form of testing deals with testing of code with external dependency

Note:

Even we can automate the UI level testing by using Selenium, Squish etc

The Ideal Test Pyramid

Based on your project, the test pyramid may vary. But most often the bottom layer is always reserved for Unit test.

Except the bottom and the top layer, the rest of the icing layers on pyramid is a subjective topic and it also depends on your project needs and vary accordingly.

At the top we have UI test/System test and so on etc.

But, Still, Why we need unit testing?

The cost of finding and fixing bugs increases over time. The more bugs you catch in the initial phase the more cost effective your project would be. Because as the application moves  to different stages in it's application life cycle, the things gets costlier in terms of time and money.

For example the bug that you caught in early unit testing phase might be fixed in a day or no time. This would save money and resources. However, Imagine a same bug caught in later stage of application life cycle. That bug would then come back with many escalating stages and each stage has resources, time and cost involved. Hence the same bug in later stage would cost more days, more resources and occupy more time.

A graphical representation of the same would help you understand this in lucid way.


A word to the wise

For test driven development you are not expected to test everything, also it is wise to understand what to test and what not to test when it comes to unit testing. Because there are other types of testing where those relatable scenarios gets covered. An ideal test pyramid example mentioned above reflect the same fact. 

Some people try to overuse unit testing so as to maximise their test coverage. They will force themselves to write unit testing for every part of code they write.
for example:  testing private methods, testing method with void return types. 

But, please note that this is not what unit testing is all about. If you want to test your private method then don't make it public first of all, try to encapsulate it in another class and make a message passing through a public method to that class in order to test that method. This article would enlighten you more on this topic.

A second word to the wise

Do not overuse mocks because as the stack of unit test suits increases it makes the execution of tests slower .

Mock is good in order to act as a “test double” for your external dependencies but it also makes your test slow and fragile.

Also, your entire team needs to follow the compliance with unit testing. Because if you are the only one writing it then every time something changes by someone you have to bear the consequences, so it is better that the entire team is following this art of unit testing.

Decide whether you want test driven development (TDD- unit testing while developing something) or test development (TD - unit testing after developing something) approach with unit testing.

Unit Testing in Action

Those who want to try out unit testing please refer this free article covering practical approach of unit testing from Manning publications practical approach

References

Comments