At first glance we may state that JUnit tests are good because they test our code, they are good because they prove that what we did works, but that is only one side of it.

A while ago I was told to write test for old legacy code and after couple of days I end up with 20% coverage, simply speaking I failed. When my tests started to look like Frankenstein I told to myself that it makes no sense. I was wondering what’s wrong with me, and came into conclusion that the problem is somewhere else. It was like a snow ball coming into my face, the production code was simple not object oriented enough and not well crafted. So, if you ever come into conclusion that writing some JUnit test is difficult, it may mean you’ve just got a feedback to your code.

When you write tests long enough, you will notice that you code become more modular, divided into layers, you start using dependency injection and suddenly the code is simple to cover with tests. But that’s not all, good JUnit tests might be better than javadocs. When you want to learn about some API usage, tests might be a good place to start, of course javadocs as well, however an example, is like “a picture” - worth of thousand words. So going further, tests need to be simple and readable. Each test has to be focused on testing one case, it is also a good practice to divide it into Given/When/Then section, use mocking techniques and advanced assertions (like catch-exception, assertj or hamcrest) that increases the readability a lot, and don’t worry if test name is more than 20 characters long.

Is that all? Well, if you code and test long enough within you domain e.g. databases or APIs, you should try to write JUnit test first. Soon you will notice that it’s not the code that comes first, it’s the design that you have to envision in first place.

Putting all this together: writing JUnit tests not only can improve your programming skills, but also can improve the way you are designing your code.