HowToDoInJava

  • Java 8
  • Regex
  • Concurrency
  • Best Practices
  • Spring Boot
  • JUnit5
  • Interview Questions

Top 8 Signs of Bad Unit Testcases

By Lokesh Gupta | Filed Under: Java Best practices

If you have been in software development for a long time, then you can easily relate with the importance of unit testing. Experts say that most of bugs can be captured in unit testing phase itself, which eventually get passed to quality teams, IF we follow these best practices for writing junit unit tests.

"It's overwhelmingly easy to write bad unit tests that add very little value to a project while 
inflating the cost of code changes astronomically."

Though, bad unit tests are reality and everyone who does code review, face it occasionally (may be regularly). So what constitute a bad test case? How to identify bad test cases?

In this post, I am trying to identify 8 such signs, which will provide you subtle hints, that a particular test case it bad one and needs to be updated.

Table of Contents

Test passes but not testing the actual feature
Testing irrelevant things
Testing multiple things in assertions
Test accessing the testee using reflection
Tests swallowing exceptions
Test which depends on excessive setup
Test compatible to only developer's machine
Test filling log files with load of texts
bad unit test cases
8 signs of bad unit test cases

Lets see what these pointers mean, one by one:

1) Test passes but not testing the actual feature

Believe me, I have seen such test cases in my previous projects which seems to doing lots of stuff in code, but in actual they were doing nothing. They were sending requests to server and no matter what server respond, they were passing. Horror !!

Beware of such test cases making place in your code repository, by strict code reviews. Once they make their way in your code base, they will become liability on you to carry them, build them and running them every time but without adding any value.

2) Testing irrelevant things

This one is another sign of bad test case. I have seen developers checking multiple irrelevant things so that code passes with doing SOMETHING, well not necessarily the correct thing. Best approach is to follow single responsibility principle, which says, one unit test case should test only one thing and that’s all.

3) Testing multiple things in assertions

This one seems to be similar to above sign, but it is not. Where in previous sign, test was testing irrelevant things, here in this sign, unit-test test the correct things but many of such things in one test case. This is again violation of single responsibility principle.

Well, please note that I am not encouraging the use of single assertion per test case. To test a single entity, you might need to use multiple assertions, do it as needed.

For example, one API which takes some parameters in post body and create Employee object and return it in response. This Employee object can have multiple fields like first name, last name, address etc. Writing a test case to validate only first-name, then another for last-name and another for address is duplicacy of code, without any value. Don’t do it.

Instead, write a single positive test case for create employee and validate all fields in that unit test. Negative test cases should be written separately doing only one thing and one assertion in this case. e.g. One test case for blank first name, one test case for invalid first name and so on. All such negative test cases can be validate using single assertion which expect exception in response.

4) Test accessing the testee using reflexion

This one is real bad. Trying to change the testee to suite ones need. What happen when code refactoring on testee happen. test case will blow up. Do not use this or allow to be used either.

5) Tests swalloing exceptions

I got my fair share of such test cases. They silently swallow the exception in little catch block at the end of test case. And worse is that they do not raise a failed alarm also. Exceptions are signals that your applications throws to communicate that something bad has happened and you must investigate it. You should not allow the test cases to ignore these signals.

Whenever you see an unexpected exception, fail the test case without failure.

6) Test which depends on excessive setup

I do not like test cases which requires a number of things to happen before they start testing the actual thing. Such a scenario can be like: an application which facilitates online meetings. Now to test whether a user of particular type, can join the meeting, below are the steps test is performing:

  • Create the User
  • Set user permissions
  • Create the meeting
  • Set meeting properties
  • Publish meeting joining information
  • [Test] User join the meeting
  • Pass/Fail

Now in above scenario, there are 5 complex steps which must be setup before actual logic is verified. For me, this is not a good test case.

A correct test system will have an existing user present in system for this activity, at least. It will reduce at least two steps in test case. If one can find appropriate, he can have some existing already created meetings also to make this test case really focused.

Another way to make it correct is using mock objects. They are there for this very purpose. Isn’t it??

7) Test compatible to only developer machine

This is not widely seen but sometimes visible when written by freshers. They use system dependent file paths, environment variables or properties in place of using common properties/paths, or things like this. Watch out for them.

8) Test filling log files with load of texts

They do not seems creating problem in happy days. But when rainy days come, they make the life hell by putting unnecessary text without any information in log files and make the life hell for debugger who is trying to find something hidden in those log files.

Tests are not for debugging the application, so do not put debug logs kind statements. A single log statement for Pass/ Fail is enough. Believe me.

These are my thoughts based on my learning in last few years. I do not expect you to agree with me on all above points. But might have some other opinion which is perfectly cool. But I will surely like to discuss, what you feel on topic.

Happy Learning !!

About Lokesh Gupta

Founded HowToDoInJava.com in late 2012. I love computers, programming and solving problems everyday. A family guy with fun loving nature. You can find me on Facebook, Twitter and Google Plus.

Feedback, Discussion and Comments

  1. Fraser

    July 15, 2015

    Thanks! New to programming and can tell my tests aren’t written well, nice to have a list of things to keep in mind.

    Reply
  2. L. M.

    September 15, 2014

    Thanks, i learnt a thing or two!

    Reply
  3. Amy

    August 28, 2014

    It would help if the post was written using better English.

    Reply
    • Lokesh

      August 29, 2014

      I will remember your suggestion in future. Thanks for the feedback.

      Reply
  4. Tarun

    August 25, 2013

    This post is really very nice, it is an eye opener for many developer, like me who made several mistake while writing unit test.

    Reply
  5. Brijesh

    July 6, 2013

    Loved this post for writing your expression. It is not just a collection of technical words.

    Reply

Ask Questions & Share Feedback Cancel reply

Your email address will not be published. Required fields are marked *

*Want to Post Code Snippets or XML content? Please use [java] ... [/java] tags otherwise code may not appear partially or even fully. e.g.
[java] 
public static void main (String[] args) {
...
}
[/java]

Help me fight spammers. Solve this simple math. *

Search Tutorials

  • Email
  • Facebook
  • RSS
  • Twitter

Java Best Practices

  • Best Practices List
  • SOLID Class Design Principles
  • FIRST Principles for Unit Tests
  • Unit Testing DAO Layer
  • Unit Testing Best Practices
  • 8 Signs of Bad Unit Tests
  • Exception Handling Practices
  • 13 Spring Configuration Tips
  • Web App Perf Improvement

Popular Tutorials

  • Java 8 Tutorial
  • Core Java Tutorial
  • Java Collections
  • Java Concurrency
  • Spring Boot Tutorial
  • Spring AOP Tutorial
  • Spring MVC Tutorial
  • Spring Security Tutorial
  • Hibernate Tutorial
  • Jersey Tutorial
  • Maven Tutorial
  • Log4j Tutorial
  • Regex Tutorial

Meta Links

  • Advertise
  • Contact Us
  • Privacy policy
  • About Me

Copyright © 2016 · HowToDoInjava.com · All Rights Reserved. | Sitemap