Click here to Skip to main content
15,881,803 members
Articles / DevOps / Testing
Tip/Trick

How to make your code more unit test friendly and better

Rate me:
Please Sign up or sign in to vote.
4.57/5 (3 votes)
19 Apr 2010CPOL2 min read 14.8K   5  
How to make your code more unit test friendly (and better)You just simply split your code into small classes and methods while ensuring you follow the principles of Separation Of Concerns and Single Responsibility.If you have a big method you want to unit test, you should use the...
How to make your code more unit test friendly (and better)

You just simply split your code into small classes and methods while ensuring you follow the principles of Separation Of Concerns and Single Responsibility.

If you have a big method you want to unit test, you should use the “Extract Methods” refactoring. Simply select some code that does “one thing” and extract that code into a new method. Then make a unit test for the method.

Ideally each class/method in a system should have one single responsibility and each method in a class should only do one small task.

In practice, not every method in a system can be a simple small one. Often, there are methods that have a large and complex responsibility. E.g. a FindBrokenLinksOnTheIntranet method.

A way to avoid a Unit Test Hell is to ensure that it does not have value to unit test a method like FindBrokenLinksOnTheIntranet.

This can be done by letting the method pass on all important work (e.g. work that is worth a unit test) to other methods.

This is exactly what we are doing for method A in the diagram below.

A1 is the method before refactoring. A2 is the same method after refactoring. 3 code segments (B, C and D) are extracted into new methods.

The method (A2) is now calling other methods (B, C and D) to do the actual work and there is now no value in making a unit test for A2 (Perhaps an integration test, but not a unit test). Instead you should of course consider if it has good value to make unit tests for method B, C and D.



If e.g. method B seems complex to unit test, you should also consider extracting code segments in B and make B “not unit test worthy”.

This is so simple and I like to keep stuff simple. :)

If you "extract" your code correctly and you have focus on testing business rules (in a unit test way - not in an integration test way), then you do not really need the complexity of stuff like mocking, stubbing and dependency injection.

Does anyone dare to prove me wrong on this? :-\

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer (Senior) Vestas Wind System A/S
Denmark Denmark
Mikael has been developing software for more than 20 years. Today he is working for Vestas Wind Systems A/S, doing development mostly in Microsoft Visual Studio.

Comments and Discussions

 
-- There are no messages in this forum --