Create tests that ensure all your pieces fit together and execute the way you planned.
1. Wait, integrated or integration?
Avoid the term integration because it leaves too much ambiguity: "Do you mean that this tests the integration points?" or "So, this connects all the pieces together and shows this does what we want?"
Integrated takes away that uncertainty because it explains that, yes, they are connected. If we want to check that contracts are correct, we want contract testing. Generally this is not needed unless you are building loosely couple applications (more on that another time).
2. Why is integrated testing so important?
We generally know what we mean to create with our coding, and we can validate pieces of that with unit tests. However, ensuring the application delivers what is supposed to (value to users), we need to make sure everything together does that.
This can be interpreted at many different levels:
We need everything to do what we think it will, and without exercising all of that logic in the same action, it is impossible to be sure.
3. Do these tests take a long time to run?
Not necessarily. You can definitely write tests that bring up the entire app context and wire everything together, but you don't have to.
This is another area of testing that might expose some design flaws in your app. Relying on the framework (Spring Boot) so deeply, you need it to test your business logic is a bad idea. You should separate the value of your app completely from your toolset.
Think of it this way: can you use a completely different method of displaying your app to the browser with a day of work? This depends on how big your app is, but you get my point.
4. Really, what could happen?
Many times when coding, you end up in a bubble. You must concentrate on smaller logic pieces at once, and many times what is a great idea on a micro level doesn't work on a macro level.
A method throws an IllegalArgumentException when a String passed to it is empty or null. The consuming Controller has nothing to handle that exception and display a message (as friendly as possible) to the user. It just blows up with the default error page served by Tomcat.
At the VERY LEAST, an integrated test makes us think through this entire scenario and adjust accordingly. Ideally, a test exists to exercise this situation and catches if/when it regresses.
Whew, now that you got that out of the way, check out the other types of testing you should be doing in Spring Boot.
Thanks for reading and I hope this was helpful!