Most of us have faced beliefs that go unquestioned. Such ideas can vary from small daily matters such as grocery shopping to something as serious as religious matters. In my case, it was a professional belief, specifically whether or not integration tests are too slow.

There was a belief in our squad (and our chapter as well) that integration tests were slow and this belief made us not put this issue in our technical debts backlog and we all accepted it as a fact. It continued until the build time in some microservices exceeded 10 minutes and teammates started complaining about them. The first reaction was avoiding integration tests as much as possible and using unit tests instead. I know that it is not a wise decision against which there are many arguments, but It was the decision that the team made. In this post, we will see how this issue got resolved and the build time in our microservices decreased to half.

Finally, over a weekend, I decided to follow this issue and find an answer to the question: Why are our integration tests that slow? I started with writing down all the things I was skeptical about but my mind was just obsessed with @SpringBootTest.

Following the First Suspicion

Whenever our tests were running, I saw the Spring logo showing up several times. I thought that @SpringBootTest loaded the full application context per each test class. After a ten-minute search, I realized that all my assumptions were wrong. I found the point in the Spring docs:

Once the TestContext framework loads an ApplicationContext (or WebApplicationContext) for a test, that context will be cached and reused for all subsequent tests that declare the same unique context configuration within the same test suite.

So why did it still load the context per each test class? Actually, it did not. I got this by counting the context loads by a specific piece of text in the log (which is repeating every time the Spring loads the application context).

#java #optimization #experience #tests #springboot