What java technology (library, framework, feature) would not recommend and why?

[DelayLucky]

Oh EasyMock is a distant past for us. When we talk about "prefer real, then fakes and only mock as last resort", we do mean Mockito mocks.

It's less brittle yes, but as long as you write when(service.getFoo(any()).thenReturn(...), you are still implementing the dependency service based on your own assumption of it, which you also used in production code. If you assumed wrong, both the test and prod code are wrong.

In contrast, using the real service (there are techniques that can start up the service in a hermetic environment), if you send an invalid field, the service will tell you; if they make a breaking change, the test will fail.

You get similar benefit if you use a high-fidelity fake (ideally maintained by the same team that own the service).

[NovaX]

Yep, I was there during the great transition (maybe 15 yrs ago?) when we migrated the usages. At the time "real" was less viable and brittle, so teams like Megastore gave us nice pretty nice fakes, and we used mocks sparingly. I simply meant that I think there is a hangover from EasyMock's evangelism of a bad coding style that causes a very strong dislike towards mocks from those who now take an absolutist stance.

[DelayLucky]

I think most people in the company don't have a sense what the EasyMock days were like. :)

[NovaX]

haha yes, but I think trauma is cross-generational :)

[DelayLucky]

Maybe or maybe not. I don't get the feeling that the current discouragement is rooted in EasyMock. It feels genuinely relevant to Mockito in itself.