Mistakes which makes your code difficult for unit testing

One of the most essential part of software development is writing unit tests. Unit tests are the solid proof that a piece of code works well in standalone mode. More than saying a piece of code works functionally fine, good unit test ensures that the code is clean and modularized.

More than writing unit tests, its important to write unit testable code. If one is facing difficulties while writing unit tests, that does mean that the code which for which you are writing unit tests in not clean, in other words, its not unit testable.

Here are few mistakes to avoid while coding, which can make sure your code is clean and unit testable.

1. Static Methods

A pure static method possibly can never be a threat for unit testing. But a static method which hides its dependencies might be difficult to stub, which makes your code hard to test.

Consider below example,

class HardToTestCode{
public void getUserStory(){
     
     UserStory userstory = UserStoryHelper.getUserStory("sprint");
        .....
}
}
class UserStoryHelper{
public static getUserStory(String userStory){
 
       DbHelper helper = new DbHelper();
       return helper.featchUserStory(userStory);   
   }
}

Here getUserStory method from HardToTestCode class is using the static method getUserStory which is defined in UserStoryHelper class. This method is using a DbHelper to fetch the userStory, since the dependencies of this static method is hidden, its difficult to mock this method.

2. Singleton implementations

Singleton is one of the most used and most debatable design pattern. Few of the developers call it anti pattern, since it interferes alot while writing unit tests.

One of the main reason, why singleton produces hard to test code is, they lie about their dependencies and controls their own initialization and life cycles. Singleton classes carries a global state all around the test suite, makes your unit tests order-dependent.

3. Alot of new operators

new Operators can cause the same problem as that of singleton classes. If a class is lying on its dependencies and initializing some dependencies in its constructor, that makes hard to stub a new operator.

class HardToTestCode{
public void getUserStory(){
     
        UserStoryHelper userstory = new UserStoryHelper();
        .....
}
}
class UserStoryHelper{
DbHelper helper = null;
public UserStoryHelper(){
     helper = new DbHelper();
   }
}

Here in the example, UserStoryHelper class is hiding the dependency DbHelper.

4. Non deterministic dependencies

Non deterministic dependencies are the dependencies whose behaviour can change over time or situation.

Consider the below example.

class HardToTestCode{
public void getUserStory(){
     
   long value = new UserStoryHelper().getUserStoryExpiredDate(23122020530);
...........
   }
}
class UserStoryHelper{
public void getUserStoryExpiredDate(long dateValue){
      Date currentTime = new Date();
      return currentTime.now() - dateValue;
          
   }
}

Here its hard to write the assert case since currentTime.now() is dependent on time and produces different values each the time test runs.

A well written, loosely coupled code always makes unit testing easy. Well unit testable code always reduces the effort developer has to put when there is a change required in the code. A unit testable code will not just makes sure your piece of code works fine, but makes your code easy to maintain and extend as well.