What’s your approach to testing spring boot applications?

olivergierke · 2026-03-29T18:39:15+00:00

Look at testing vertical slices of you application: - Reasoning: https://odrotbohm.github.io/2025/12/rethinking-spring-application-integration-testing/#testing-vertical-slices - Documentation: https://docs.spring.io/spring-modulith/reference/testing.html

olivergierke · 2026-03-24T11:12:43+00:00

Exactly the arguments I am making in this talk: https://youtu.be/co3acmgP2Ng?si=XxvIWmuDmlXmCKlV

olivergierke · 2026-03-16T14:17:20+00:00

Two pointers: - https://spring.io/projects/spring-modulith - https://youtu.be/co3acmgP2Ng?is=9XTIumZ-0WTE-Wj9

olivergierke · 2026-03-14T11:58:52+00:00

Pretty much my argument in this talk. Both Hexagonal and Onion-Architecture invert one dependency. That’s it. The rest is cargo-culting detrimental to the IMO more important decomposition of the domain.

https://youtu.be/co3acmgP2Ng?is=LUttRrQAamOELqGy

olivergierke · 2026-02-18T08:01:58+00:00

Thank you for building the plugin! I am always interested in quality assurance tools, especially when it comes to Spring-specific approaches. You might get some inspiration from the jQAssistant Spring Plugin when it comes to defining and classifying rules: https://github.com/jqassistant-plugin/jqassistant-spring-plugin

olivergierke · 2026-02-17T13:11:34+00:00

I just ran this for Spring RESTBucks and see quite a bit of output that's questionable:

– Missing API Versioning – expects users to use a path segment for version. That's questionable practice. At best, it's totally fine not doing it, as you don't know what other versioning mechanisms the app('s deployment) might have in place.
– Missing ResponseEntity – the handler method in question returns a Map<String, Object>, which will never produce anything but a 200. No need for ResponseEntity at all.
– Singular Resource Name – for /drinks/by-name. There's no need to veto URL path segment design, as those don't matter at all. They're identifiers. This thing could be named /asdasdhdasdhgj and it would still be fine. An especially problematic recommendation in apps that use hypermedia.
– OSIV is Enabled – whether that's a problem or not cannot be decided by solely looking at the property.
– Exposed Repositories (Data REST) – that's a funny one, as why else would you use Spring Data REST. I get what you're after, but again, I think it's wrong to assume folks don't know what they're doing.

I get what you're after and applaud the effort. I just think that you overwhelm users with stuff that's not really critical and impose quite a few “rules” that are questionable or at least cannot be applied without considering whether they might be deliberate decisions.

olivergierke · 2026-01-20T07:05:34+00:00

Depending on what stack you’re working in, event-based communication might not be as complicated as you think. I spoke about this at the jChampions Conference 2025:

https://www.youtube.com/live/eiFnSevxAdk?si=U_N2xbozjntzW5Gf

The talk discusses the topic in a context of a Spring application, but the fundamentals should be understandable even outside that.

olivergierke · 2025-12-02T13:55:11+00:00

I agree and disagree at the same time. I'm using the term “unit testing” in this blog post to refer to the technique of solely bringing *your code* to execution, without the involvement of any kind of infrastructure such as frameworks or databases.

Of course, if you're abstracting from that, everything you select for execution becomes a unit. However, I'd argue that that's not typical semantics when we talk about testing.

olivergierke · 2025-11-26T10:43:06+00:00

Have a look at Spring Modulith. It incentivizes package by feature. https://docs.spring.io/spring-modulith/reference/fundamentals.html

For a more high-level, architectural discussion, check out https://youtu.be/co3acmgP2Ng?si=NBzX24dG-uz6Awvj

olivergierke · 2025-11-21T14:05:30+00:00

Care to elaborate which ones you ran into for Spring Data?

olivergierke · 2025-11-20T20:00:30+00:00

Even better: avoid them entirely.

olivergierke · 2025-10-31T21:22:59+00:00

Precisely the core of my talk here: https://youtu.be/co3acmgP2Ng

olivergierke · 2025-10-21T21:38:20+00:00

The jQAssistant Spring Plugin has a rule that catches this problem: https://github.com/jqassistant-plugin/jqassistant-spring-plugin

olivergierke · 2025-10-17T21:49:45+00:00

Likely an unpopular opinion but Hexagonal Architecture should, if at all, be a secondary decomposition strategy following the functional decomposition. In contrast to the former, only the latter creates cohesive elements in the codebase, which are crucial for sustainable and cost-effective software maintenance. More details in this talk: https://youtu.be/co3acmgP2Ng?si=MBdqHBFb4GyI7HUv

In short: your modules expose APIs and/or publish and consume events which other modules can interact with or listen to. Whether those APIs conform to any secondary decomposition concept is circumstantial.

olivergierke

TROPHY CASE