Clean code

Testing the Persistence Layer With Spring Boot @DataJpaTest

Learn how to test Spring Boot repositories using @DataJpaTest. Learn what should be tested on the persistence layer and how.

Testing Web Controllers With Spring Boot @WebMvcTest

Learn how to test Spring Boot web controllers using @WebMvcTest. Learn what responsibilities a controller has and how to test them.

Spring Boot Unit Testing

Learn how to write unit tests for Spring Boot applications. Learn the technical details necessary to write good unit tests.

How to Make Your Tests Readable

In this article, we will learn different ways to improve test readability. Tests document how the system should behave. They also act as self-verifying executable specifications.

How to Create a Test Data Builder

Learn how to use the test data builder pattern to make it easy to create objects for tests. Learn how to reduce boilerplate code with Lombok.

How do I test private methods?

What is the best way to test private methods? Should I use some library or use reflection? Can I just make the method public?

Code quality checks

Code quality is a weak spot in nearly every software project. This is especially true for legacy projects. What once was elegant, over time became rougher and finally incomprehensible. Monitoring and fixing code quality issues is something that has been proven to increase the quality of the application and decrease the delivery time to stakeholders.

Testing myth #2: Unit tests are not worth it

There are a lot of developers and managers who think that writing unit tests is just extra work. Suggesting that we should write more unit tests seems to receive ill responses. I think there are many people out there who still don’t understand the purpose of unit testing. This kind of thinking is probably the result of following kind of experiences: Writing unit tests is really hard and time consuming. Even small changes in requirements keep breaking the unit tests. Unit tests are not finding any real bugs. It is not that writing unit tests is somehow fundamentally laborious. These kind of experiences are symptoms of something else.

Testing myth #1: Writing tests slows you down

Let’s assume we have decided to increase the stability of our software. So we decide to write tests for our code. The problem is that the customer is requesting new features and deadlines are approaching.

Avoiding unnecessary null checks

The most common reason for writing null checks is that you run into a null pointer exception. The second most common reason is that you happened to think about it at some certain case. The problem is that you are not probably handling null in every single method call. This means that there are potential bugs lurking everywhere. Null pointer exceptions are bad. Would it not be better if you did not have to check for nulls at all?