6 Steps to help you debug your application

As a developer sooner or later you will encounter bugs, be it small ones or production breaking bugs.
Now it is your task to find and fix the bug as soon as possible.
In this article I will list the techniques I learned over the course of many years debugging web applications in the hope that it will help you be better and more efficient in bug hunting. Continue reading

How to write bug free code – State

A lot of bugs are in some way related to state. So that is what we will be talking about today. We will start off with a quote from Einstein:
“Insanity: doing the same thing over and over again and expecting different results. ”

Code should be consistent, calling the same function with the same input should return the same result during the whole life cycle of the object. Insanity and bugs will follow if this rule is violated.

This sounds logical, but in practise it is quite easy to violate this principle. The main cause of this, is object state. This state is used in a lot of functions, and can thus affect the behaviour of our program at runtime. This principle can be even be seen in the most basic of examples (imagine the impact on a more complicated class…).

Given the following class:

Lets see how this state affects the behaviour of our object:

All it takes is a simple setter, and calling the same function over and over again with the same parameter (void in this case) does not have to result in getting the same output. This means the object is not safe, and the state should be checked every time we call getName(), since we have no way of knowing if the function might return null. (bonus points if you notice that you also get null if you do not call the setter at all!)

As developers we usually work on projects in teams, and even if you always do a null check on getName(), one of your colleagues might forget at some point, and that code might result in a null pointer at some point in time.

There are two ways of avoiding the consistency problem. The first is creating constant state (immutability), or passing the state as an argument, and thus make the method stateless.

Lets see what an immutable version of Person would look like:

There are a couple of things that have changed. First of all, we now use the final keyword for our variable name. This makes sure the variable can be assigned only once (in the constructor). In the constructor we also throw an exception if the parameter is null. Thus, the object cannot be instantiated in an illegal state, and since we lack a setter, the state cannot be altered during the lifecycle of the object. (for the sake of argument, we will ignore reflection for this discussion)
This means we now have a safe object. Every time we call getName(), the same result will be returned, and Einstein is again a happy man. Also, we can now remove all null checks on getName(), since it is now impossible for it to be null.

The downside of this, is that in order to change the name, you need to create a new object with a different name, but the consistency of immutability is well worth the trade-off.
A second downside is that since you do not have any setters, arguments can only be passed as constructor arguments, and this can lead to very ugly constructors. If this is the case, I suggest taking a look at the builder pattern, which deals with this problem quite well.

For the second solution Java can help us as well, with the static keyword. Let’s take the following example:

As you can see, sayHello1() uses the state of Person, and as we just learned, this would be safe if name was immutable, but we can avoid the issue entirely if we instead pass the variable as an argument. No matter the state of Person, sayHello2() will always return the same value when called with the same argument, and thus Einstein will again, be a happy man.

So, does this mean you should make all your classes immutable?
No, sometimes things are just optional, or you have no way of knowing the value for certain properties at object creation. However, it can still be a good practice to transform the mutable object to an immutable object once this is possible, MutablePerson -> Person and only use the immutable object in your buisnesslogic
My rule of thumb in this case is: you should make everything immutable, and only make them mutable with good argumentation.

In conclusion.
We learned that state can cause our methods and thus our application to behave differently. This is a mayor cause of bugs (especially null pointers). The solution is to be aware of state, avoid it if possible by using static methods, or if you cannot avoid it, make your object as immutable as possible.

Integration testing on REST urls with Spring Boot

We are building a Spring Boot application with a REST interface and at some point we wanted to test our REST interface, and if possible, integrate this testing with our regular unit tests. One way of doing this, would be to @Autowire our REST controllers and call our endpoints using that. However, this won’t give full converage, since it will skip things like JSON deserialisation and global exception handling. So the ideal situation for us would be to start our application when the unit test start, and close it again, after the last unit test.
It just so happens that Spring Boot does this all for us with one annotation: @IntegrationTest.
Here is an example implementation of an abstract class you can use for your unit-tests which will automatically start the application prior to starting your unit tests, caching it, and close it again at the end.