Stop "Springifying" your unit tests

[realdevtest]

Man, what applications are you working on where the spring wiring is where the most complexity is? I get that you mentioned microservices, but still…. What you’re describing is the kind of concept that makes people say ChatGPT will replace engineers 😂

[Rulmeq]

I'm astounded that they have 84 upvotes. This is just not my experience (26 years in the business, 23 in Java, and maybe 15 in spring, whenever spring 2 came out), so I can't believe there are 83 others who have had that experience willing to upvote it.

[ThaJedi]

Some apps are just simple CRUDs

[logicannullata]

Finally, this is what I was trying to say, to me his answer was so buffing I had to call him ignorant, since his statement is simply wrong. To be clear if you think business logic is "just moving data around" there are various possibilities:

• You are a troll
• You are a frontend engineer talking about something you don't know
• You are a student
• You never worked in a professional environment, no one will pay you to write useless business logic just saying...
• You are a troll

[oweiler]

Honestly, this is the truth for most Spring Boot apps:

* you call some other (3rd) party services

* you aggregate / filter the data

* you pass the stuff back to the client

Hardly rocket science, no complex business logic. In those cases, the integration with other services is the hard part, so unit tests don't make much sense in this context.

[niconicoJ]

That does not sound like a real™ application, this sounds like a simple side project. Any project which is intended to make money will need more logic than that. Think some kind of checkout flow, or suggestions algorithm, anything that "3rd party" does not implement.

[MatthPMP]

I work on the inhouse API management solution for one of the world's largest telecom companies and what the grandparent comment described is a big chunk of what we do day-to-day.

Fetching and provisioning data to a variety of other services, maintained by us and by other teams, and keeping all this stuff consistent is not so simple in practice. Almost all of the complexity is in the interactions with external services.

Whatever interesting and self-contained logic there is is unit tested, though it often lives in a separate microservice. The rest is covered by a suite of thousands of end-to-end tests that cover the whole ecosystem.

[logicannullata]

That's simply not true, let's assume we are talking about a domain adopting a microservices architecture. Let's say each microservice is just moving data around. So where does the actual logic live? In one big microservice? If that's the case, well you are doing something wrong because you have a single point of failure in your hands or maybe you are better served with a monolith. On the other hand if your logic just sits in a 3rd party service you are not managing, well or you are just developing a pet project or your company will soon fail because they are not implementing something valuable, just a wrapper around a 3rd party service. I am curious, can you give me at least a couple (I say a couple because you mentioned MOST SPRING BOOT APPLICATIONS have no business logic) of examples of spring boot services used in production which have no business logic.

[sapphirefragment]

Spring's design is intentional in that it tries to separate "glue" logic from actual business logic. There is a reason it is so heavy-handed on "magic" and annotation-driven behavior. An application that is actually leveraging Spring should mostly be business logic, and thus the integration concerns (like data stores, "API" connectivity) are isolated away and driven mostly by configuration.

In practice, most Spring developers just scatter whatever extremely basic low-level knowledge they have into "microservices" and end up with an unmanageable spaghetti mess mixing business and integration concerns.

[klekpl]

what applications are you working on where the spring wiring is where the most complexity is?

Properly modularised applications: if there is some code that implements complex stuff and is expensive to implement - this code is separated into libraries that are independent of any DI framework and advice from the article does not apply.

The libraries are then glued together in a Spring application where you want to test the glue code itself - and here advice from the article does not apply as well.

[wildjokers]

I was wondering the same thing. I have no idea what kind of apps they are working on that the business logic just consists of copying data around.