Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stepping down as Mockito maintainer after ten years

github.com

Post reply on HN
Print view View original

71–80 of 220 posts

Re: Stepping down as Mockito maintainer after ten years

#71

Post by emodendroket »

t-writescode wrote: post #49

Wow, there's a lot of anger in some of these posts. I've been using Mockito for about 4 years, all in Kotlin. I always found it to be "plenty good" for like 99% of the cases I needed it; and things more complicated or confusing or messy were usually my fault (poor separation of concerns, etc). I regularly found it quite helpful in both its spy() and mock() functionality. I never found it meaningfully more or less use…

At the end of the day I think there's nothing wrong with the tool itself. The problem is that mocking and spies make it easy to not bother properly isolating the effects of a function for testing and then you end up having a test where 95% of it is setting up an elaborate array of mocks to create the condition you wish to test, which are completely incomprehensible to the next person trying to read it.

Re: Stepping down as Mockito maintainer after ten years

#72

Post by throwaw12 »

njitbew wrote: post #16

I respect the maintainer's decision, but I don't understand the justification. > but when it was communicated with Mockito I perceived it as "Mockito is holding the JVM ecosystem back by using dynamic attachment, please switch immediately and figure it out on your own". Who did the communication? Why is dynamic attachment through a flag a problem, and what was the solution? Why is "enable a flag when running tests" n…

> Why support Kotlin in the first place?

Some complexities are discovered along the way, people don't know everything when they start.

They could also drop the support after some time, but then it would have created other set of problems for adoption and trustworthiness of the project.

Re: Stepping down as Mockito maintainer after ten years

#73

Post by philipwhiuk »

krackers wrote: post #8

>Mockito 5 shipped a breaking change where its main artifact is now an agent. That's because starting JVM 22, the previous so-called "dynamic attachment of agents" is put behind a flag Wouldn't this hold back enterprise adoption, the same way breaking changes meant that Java 8 was widely used for a long time?

JVM 22 stuff isn't going to be mainline at enterprise for years. Java 25 is the first LTS release that includes it and it's only just been released.

Most places are just about getting rid of 8 for 17.

Re: Stepping down as Mockito maintainer after ten years

#74

Post by okillbite »

lovich wrote: post #66
pron wrote: post #31

> To me, it felt like the feature was presented as a done deal because of security. Not security, but integrity, although security (which is the #1 concern of companies relying on a platform responsible for trillions of dollars) is certainly one of the primary motivations for integrity (others being performance, backward compatibility or "evolvability", and correctness). Integrity is the ability of code to locally de…

What am I missing that makes this change a massive headache if just setting a flag gets the old behavior?

I haven't read the discussion but this seems like the obvious answer considering the flag only needs to be set during test.

Presumably this might miss some edge case (where something else also needs the flag?) though an explicit allow of the mockito agent in the jvm arg would have solved for that.

Re: Stepping down as Mockito maintainer after ten years

#76

Post by pron »

okillbite wrote: post #74
lovich wrote: post #66

Earlier quoted context omitted.

What am I missing that makes this change a massive headache if just setting a flag gets the old behavior?

I haven't read the discussion but this seems like the obvious answer considering the flag only needs to be set during test. Presumably this might miss some edge case (where something else also needs the flag?) though an explicit allow of the mockito agent in the jvm arg would have solved for that.

> though an explicit allow of the mockito agent in the jvm arg would have solved for that.

You can and should explicitly specify Mockito as an agent in the JVM configuration, as it is one.

Re: Stepping down as Mockito maintainer after ten years

#77

Post by cletus »

My second project at Google basically killed mocking for me and I've basically never done it since. Two things happened.

The first was that I worked on a rewrite of something (using GWT no less; it was more than a decade ago) and they decided to have a lot of test coverage and test requirements. That's fine but they way it was mandated and implemented, everybody just testing their service and DIed a bunch of mocks in.

The results were entirely predictable. The entire system was incredibly brittle and a service that existed for only 8 weeks behaved like legacy code. You could spend half a day fixing mocks in tests for a 30 minute change just because you switched backend services, changed the order of calls or just ended up calling a given service more times than expected. It was horrible and a complete waste of time.

Even the DI aspect of this was horrible because everything used Guice andd there wer emodules that installed modules that installed modules and modifying those to return mocks in a test environment was a massive effort that typically resulted in having a different environment (and injector) for test code vs production code so what are you actually testing?

The second was that about this time the Java engineers at the company went on a massive boondoggle to decide on whether to use (and mandate) EasyMock vs Mockito. This was additionally a waste of time. Regardless of the relative merits of either, there's really not that much difference. At no point is it worth completely changing your mocking framework in existing code. Who knows how many engineering man-yars were wasted on this.

Mocking encourages bad habits and a false sense of security. The solution is to have dummy versions of services and interfaces that have minimal correct behavior. So you might have a dummy Identity service that does simple lookups on an ID for permissions or metadata. If that's not what you're testing and you just need it to run a test, doing that with a mock is just wrong on so many levels.

I've basically never used mocks since, so much so that I find anyone who is strongly in favor of mocks or has strong opinions on mocking frameworks to be a huge red flag.

Re: Stepping down as Mockito maintainer after ten years

#78

Post by gerdesj »

t-writescode wrote: post #49

Wow, there's a lot of anger in some of these posts. I've been using Mockito for about 4 years, all in Kotlin. I always found it to be "plenty good" for like 99% of the cases I needed it; and things more complicated or confusing or messy were usually my fault (poor separation of concerns, etc). I regularly found it quite helpful in both its spy() and mock() functionality. I never found it meaningfully more or less use…

"Wow, there's a lot of anger in some of these posts."

If I was OP I'd retire happy knowing that a very thankless job is well done! Given what it does: the more outrage the better. Projects like Mockito call out the lazy and indolent for whom they are and the hissing and spitting in return can simply be laughed at.

10 years this bloke has given his time and effort to help people. He states: nearly a third of his life.

I'll raise a glass and say "was hale" or perhaps wassail as an Englander might.

Re: Stepping down as Mockito maintainer after ten years

#79

Post by LgWoodenBadger »

cletus wrote: post #77

My second project at Google basically killed mocking for me and I've basically never done it since. Two things happened. The first was that I worked on a rewrite of something (using GWT no less; it was more than a decade ago) and they decided to have a lot of test coverage and test requirements. That's fine but they way it was mandated and implemented, everybody just testing their service and DIed a bunch of mocks in…

“The solution is to have dummy versions of services and interfaces that have minimal correct behavior”

If you aren’t doing this with mocks then you’re doing mocks wrong.

Re: Stepping down as Mockito maintainer after ten years

#80

Post by WD-42 »

t-writescode wrote: post #49

Wow, there's a lot of anger in some of these posts. I've been using Mockito for about 4 years, all in Kotlin. I always found it to be "plenty good" for like 99% of the cases I needed it; and things more complicated or confusing or messy were usually my fault (poor separation of concerns, etc). I regularly found it quite helpful in both its spy() and mock() functionality. I never found it meaningfully more or less use…

Is it anger? The agent thing maybe. The other two points seem to boil down to:

1. Kotlin is a hack and 2. Rust is more fun.

Pretty understandable why one would simply want to move on to greener pastures.

Post reply on HN