When I started learning Spring, I noticed something about many of the tutorials I found.
They often showed how to use a feature, but not always why it worked or when you should choose one approach over another.
I learn best by building things and documenting what I discover, so I started a project called spring-by-example.
The idea is simple: instead of building one large application, I’m creating a collection of small, focused examples where each example explores a specific Spring concept with clear explanations, tests, and documentation.
I’m happy to say that I’ve now completed Module 11 - Spring Testing. 🎉
The module covers:
- Unit Testing with JUnit
- Spring TestContext
@SpringBootTest@MockitoBean@TestConfiguration- Integration Testing
One of the things I enjoyed about this module was understanding the different levels at which a Spring application can be tested.
I started with unit testing, where the goal is to test a class in isolation without starting the Spring application context. This helped reinforce the idea that not every test needs Spring.
I then moved into the Spring TestContext, where Spring can create and manage the application context for tests. This makes it possible to test components using the same dependency injection and configuration mechanisms used by the application.
From there, I explored @SpringBootTest and how it can be used to load the full Spring Boot application context. This helped connect the concepts of application startup, component scanning, dependency injection, and testing.
I also explored mocking Spring-managed dependencies. With Spring Boot 4, the approach uses @MockitoBean to replace a bean in the test context with a Mockito mock. This makes it possible to isolate the component being tested while still using Spring's dependency injection.
Another interesting part was @TestConfiguration, which allows test-specific beans to be defined without changing the production configuration. This was a useful way to understand how Spring's configuration system can be customized specifically for tests.
Finally, I explored integration testing, where multiple parts of the application work together instead of being tested in isolation.
The integration testing example uses a controller, service, and repository together, starts the application on a random port, and makes a real HTTP request using TestRestTemplate.
That helped put the previous testing concepts together and made the distinction between unit tests and integration tests much clearer.
The goal isn’t just to collect Spring annotations and APIs. I’m trying to understand how Spring works under the hood, how its features fit together, and why these features exist, one concept at a time.
The project is open source, and I’m continuing to build it as I learn:
🔗 GitHub: https://gith.ub/dsAQrAU5
🔗 GitLab: https://gitl.ab/gfDEyGH3
There’s still a long way to go, but completing another module feels like a good milestone. 🚀
Next up: Module 12 - continuing deeper into the Spring ecosystem and building on the concepts covered so far.
If you’ve worked with Spring testing before, what’s one testing concept you think developers commonly misunderstand?
Top comments (0)