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

81–90 of 220 posts

Re: Stepping down as Mockito maintainer after ten years

#81

Post by philipwhiuk »

xyzzy9563 wrote: post #57

>Energy drain because of JVM agent change So funny, he essentially works for free for 10 years, then finally burns out because he doesn't want to put up with a bunch of annoying work? This is why you shouldn't work on open source unless you have a business strategy to get paid. Tons of stuff in life is 100x more annoying and exhausting if you aren't making any money. If he was making $1 million per year from this I d…

> If he was making $1 million per year from this I doubt his energy would be drained.

People quit all the time from highly paid jobs due to burnout. This absolutely does not follow.

Re: Stepping down as Mockito maintainer after ten years

#82

Post by exabrial »

Mock is effective when developers keep applications at 4-5 layers deep (and honestly, you don't need more than that 97% of the time: initiators, controllers, services, transports, and cross cutting concerns).

The problem is, engineers love to solve problems, and the funnest types of problems are hypothetical ones!

Yep, I was guiltily of taking DI and writing a spider web of code. It's not the tools fault, it was my attitude. I _wanted_ something hard to work on, so I created something hard to work on. Nowadays, my team and I work on a 4-5 layer deep limit and our code base is tight, consistent, and has near 99% test coverage naturally. We use mock testing for testing the single class, and of course integration test for testing requirements. Not everyone will do it this way, and that's fine, but the most important thing is actually just creating a plan and sticking to it so as to be consistent.

In the end, don't blame the tool, when you (or your coworkers) simply lack discipline.

Re: Stepping down as Mockito maintainer after ten years

#83

Post by bhawks »

| My personal take is that folks involved with the change severely underestimated the societal impact that it had. The fact that proper build support is non-existent to this day shows that agents are not a priority. That's okay if it isn't a priority, 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".

Id like to hear the platform team's perspective on this. As it stands, it is a pretty sad state of affairs that such a prominent library in the ecosystem was made out to be the scapegoat for the adoption of a platform change. It is not a healthy thing to treat the library maintainer community like this.

Re: Stepping down as Mockito maintainer after ten years

#85

Post by derriz »

tripple6 wrote: post #14
didip wrote: post #4

As someone who is not in the Java world, why does Java need a mocking library? Interface based polymorphism is not enough?

Mockito uses declarative matching style of specifying what should be mocked. You don't need to implement or even stub all of interface methods since Mockito can do it itself. It may be extremely concise. For example, interfaces may have tens methods or even more, but only one method is needed (say, java.sql.ResultSet). And finally probably the most important thing, interaction with mocks is recorded and then can be v…

That’s the seductive power of mocking - you get a test up and running quickly. The benefit to the initial test writer is significant.

The cost is the pain - sometimes nightmarish - for other contributors to the code base since tests depending on mocking are far more brittle.

Someone changes code to check if the ResultSet is empty before further processing and a large number of your mock based tests break as the original test author will only have mocked enough of the class to support the current implementation.

Working on a 10+ year old code base, making a small simple safe change and then seeing a bunch of unit tests fail, my reaction is always “please let the failing tests not rely on mocks”.

Re: Stepping down as Mockito maintainer after ten years

#86

Post by nitwit005 »

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?

It just means your test runs need to add the flag.

Re: Stepping down as Mockito maintainer after ten years

#88

Post by wging »

captainbland wrote: post #87

> That's because starting JVM 22, the previous so-called "dynamic attachment of agents" is put behind a flag. Ok am I being stupid or is the pragmatic solution not to just to enable this flag for test runs etc. and leave it off in prod?

I think the problem is that it's on his users to enable this flag, not something that can be done by Mockito automatically.

Re: Stepping down as Mockito maintainer after ten years

#89

Post by saghm »

LgWoodenBadger wrote: post #79
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.

I think the argument they're making is that once you have this, you already have an easy way to test things that doesn't require bringing in an entire framework.

Re: Stepping down as Mockito maintainer after ten years

#90

Post by mrkeen »

pjc50 wrote: post #40
nsxwolf wrote: post #32

Earlier quoted context omitted.

Absolutely the worst. 1000 line test setups that shatter into pieces the instant you try to make the simplest change to a function. Makes refactoring an absolute nightmare.

What's specifically bad about Mockito here? Poor defaults for mocks?

You've just built a calculator, and now you want to test it. Well, you have to push buttons on a calculator, so you build a robotic hand. And that hand needs a power source and some intelligence. And you need to photograph and OCR the result from the calculator screen.

This is kinda how we build software right? A little bit of "our logic" (calculation), represented as objects/actors/modules which "do things", but intermingled with million-LoC dependencies like databases and web servers.

After a while it gets frustrating setting up the robot hand and OCR equipment for each test case. Maybe it's just easier to test manually, or skip testing entirely.

At this point you can have an epiphany, and realise you only care about the numbers going in and out of the calculator, not the button pushes and pixels.

Mockito swoops in and prevents you from having that epiphany, by making it easier to keep doing things the stupid way.

Instead isolating the calculation from any IO, you can now write things like: when(finger.pushbutton(1)).then(calculator.setState(1)) when(calculator.setAnswer(3)).then(camera.setOcr(3))

(I've mostly worked in Java, but it seems like other languages typically don't let you intercept calls and responses this way)

Post reply on HN