How to Rock With JUnit


2 m read


Automated Testing, Software Testing Tools, Unit Testing

You may in some mobile application projects that require testing or you perform tests for desktop or web solutions, no matter. You will face unit tests sooner or later.

So Junit, huh? If you are looking forward to using this tech in testing you probably wish to achieve fast results which are also quite reliable. A dream come true, right? If Junit is used wisely than enormous amounts of unit tests will run at lightning speed measured in milliseconds required for one test. And you must have tests that brake only in case production code tends to be broken and not those false-positive or false-negative ones. Here is how you achieve all that:

First thing’s first

If you are going for some accurate results make perfectly sure all unit tests run in-memory. What I mean is tests read from file systems or make HTTP requests are insanely slow. Furthermore they are completely unreliable, so simply leave them until functional testing phase begins. Here is why:

  • Any tests that tend to read from a file system require locating the current operational directory in order to be correct on both development and build machines. This is hard to get done properly and has no background behind even trying to do so.
  • Files must be stored in order to be read via source control meaning you will face more issues with keeping any item inside source control updated. And again, no particular reasons of going through this exist.

The next stop: one assertion per one unit test method

Each unit test of yours should have but one assertion. This way, if any test fails you won’t feel much pain while researching for what exactly was wrong, unlike cases when various unit tests have multiple assertions. It won’t be impossible to determine the reason, but extra effort will be required and that means more time investments.

Also multiple assertions do not always occur while unit testing is in progress. Tests may face some unchecked exceptions leading to the fact assertions are not taking place after such exceptions. Junit will simply mark this as an error and will proceed to other test methods. Such things are never good and once again prove several assertions are not justified.

Now, that we are talking about assertions it’s worth noticing you should only use the strongest ones. Unit tests are not just coverage, they are more considering assertions are as strong as possible. Sure you can just have large coverage but how do you effectively determine this or that method behaves just as supposed? Unit tests can do more than looking out for defects, they can actually ensure production code works as expected. Assertions that return method value are the strongest preferred ones, but there are still ones that do verify all vital mock objects with dependencies are correctly interacted with. Such assertions work great as well.

One more thing: no skipping!

If you are aimed at results you should not skip your unit tests. Actually there are series of various ways provided to you that serve one particular purpose: skipping unit tests. Sure you can use the @Ignore annotation provided by Junit or anything else of that sort but you will gain no benefit from this and you will still be forced to test source control. So removing unit tests from that source control instead of just skipping them proves to be a fairly better practice.

Perhaps you have any thoughts on this matter? Feel free to share them through the comment section!

Realizing the importance of providing service on agreed terms, we consider all possible risks and provide efficient solutions for all possible risks and provide efficient solutions.


We use cookies to ensure your best experience. By continuing to browse this site, you accept the use of cookies and "third-party" cookies. For more information or to refuse consent to some cookies, please see our Privacy Policy and Cookie Policy