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

121–130 of 220 posts

Re: Stepping down as Mockito maintainer after ten years

#121

Post by __MatrixMan__ »

xyzzy9563 wrote: post #60
__MatrixMan__ wrote: post #59

Earlier quoted context omitted.

Disagree, its working for money that's draining. Extrinsic motivation is toxic to many things that might motivate an open source maintainer.

What about paying your mortgage, food, utilities etc.? Or is that all supposed to come from savings or inheritance?

I don't claim to have a recipe that sustains itself, I just find that my energy diminishes if I'm not doing a project for its own sake.

If after ten years the spark was gone we should be happy for that ten year contribution, but I don't think there's any reason to assume that money would've prevented the problems that motivated him to step down. Maybe it could incentivize him to muscle through after the magic was gone, but that's a different sort of thing.

Re: Stepping down as Mockito maintainer after ten years

#122

Post by jeremyjh »

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…

In retrospect - from an outside point of view - it seems they should have just declined to support Kotlin. There are other options for Kotlin, and it sounds like it makes sense for it to have something developed for that from the beginning. But probably they had no idea what they were getting into when it was first proposed.

Re: Stepping down as Mockito maintainer after ten years

#123

Post by zem »

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…

my time at google likewise led me to the conclusion that fakes were better than mocks in pretty much every case (though I was working in c++ and python, not java).

edit: of course google was an unusual case because you had access to all the source code. I daresay there are cases where only a mock will work because you can't satisfy type signatures with a fake.

Re: Stepping down as Mockito maintainer after ten years

#124

Post by jeremyjh »

vips7L wrote: post #68
xienze wrote: post #61

Earlier quoted context omitted.

IMO Mockito is fine, the problem I’ve encountered is people taking the easy way out and trying to test something that needs a real integration test with a convoluted series of mocks.

I've found that most of the time that if you need to mock, you probably just need to do an integration test.

I agree. I mostly only use mocks for external service dependencies (apart from primary application database), or library features that are very problematic to use in test. A lot of code simply should not be unit tested - if an integration test can cover the same paths its far better in the long run. Performance can become an issue but it is easier to deal with that than to spend so much time maintaining and debugging mock constructs.

Re: Stepping down as Mockito maintainer after ten years

#125

Post by lisbbb »

Freak_NL wrote: post #17
schumpeter wrote: post #15

Earlier quoted context omitted.

It also translates to “small booger”, in Spanish, which always made me question who thought the name was a good idea over there.

Why? Every name you pick is likely to be weird in one language or another. Mockito does one thing well as a name, and that is hinting strongly at what it is (a mocking library).

Wasn't it a riff on "Mojito" which was a popular drink at the time?

Re: Stepping down as Mockito maintainer after ten years

#126

Post by bluGill »

danparsonson wrote: post #102
bluGill wrote: post #70

Earlier quoted context omitted.

90% of the time (or more): you don't. The real thing is perfectly fine in a test with the right setup. Fileio is fast, I just need a test file in a tempdir. databases are fast, I just need an easy way to settup my schema. Sometimes I need the isolation but normally I do not.

Well, no - you don't. What you're describing is a very limited subset of testing, which presumably is fine for the projects you work on, but that experience does not generalise well. Integration testing is of course useful, but generally one would want to create unit tests for every part of the code, and by definition it's not a unit test if hits multiple parts of the code simultaneously. Apart from that, databases a…

Why would I want to create tests for every part of the code? I did that for years because I was taught that, but I came to realize it never mattered - if a test breaks it is because of the last thing I changed. I have a few flakey tests from time to time, but they have been not too bad to track down nd often taught me enough about how the system really worked as to be worth the time anyway.

Re: Stepping down as Mockito maintainer after ten years

#127

Post by yardstick »

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…

> burns out because he doesn't want to put up with a bunch of annoying work

It’s more than annoying work, it’s pointless work needlessly created by people other than him.

It’s like migrating from Java 8 to newer versions, the decision makers placed backwards compatibility at the back of their priority list. Literally a decade later it’s still griefing migrating users, all because “Jakarta not javax” nonsense. I’m greatly simplifying but that’s the essence of it.

Now we have some genius decision to I guess protect against untrusted code doing unexpected things. And at the same time Applets are gone and Security Manager is gone. And the reality is that Java applications aren’t run with untrusted code. The run scripts define all the jars/classes used. If there was some malicious code that wanted to run, I’m fairly confident it would also just modify the run scripts to include this new flag.

So all we’ve gained is support headache and pain, and no real net gain in practice.

Re: Stepping down as Mockito maintainer after ten years

#128

Post by supriyo-biswas »

sfn42 wrote: post #110
cowsandmilk wrote: post #96

Earlier quoted context omitted.

In part, you’re right, but there’s a practical difference between mocking and a good dummy version of a service. Take DynamoDB local as an example: you can insert items and they persist, delete items, delete tables, etc. Or in the Ruby on Rails world, one often would use SQLite as a local database for tests even if using a different DB in production. Going further, there’s the whole test containers movement of having…

I use test containers and similar methods to test against a "real" db, but I also use mocks. For example to mock the response of a third party api, can't very well spin that up in a test container. Nother example is simply time stamps. Can't really test time related stuff without mocking a timestamp provider. It is a hassle a lot of the time, but I see it as a necessary evil.

You can use a library like [1] to mock out a real HTTP server with responses.

[1] https://www.mock-server.com/

Re: Stepping down as Mockito maintainer after ten years

#129

Post by phanimahesh »

throwaway7783 wrote: post #117
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…

I'm not sure I understand. "The solution is to have dummy versions of services and interfaces that have minimal correct behavior". That's mocks in a nutshell. What other way would you use mocks?

There are different kinds of mocks.

Check function XYZ is called, return abc when XYZ is called etc are the bad kind that people were bit badly by.

The good kind are a minimally correct fake implementation that doesn't really need any mocking library to build.

Tests should not be brittle and rigidly restate the order of function calls and expected responses. That's a whole lot of ceremony that doesn't really add confidence in the code because it does not catch many classes of errors, and requires pointless updates to match the implementation 1-1 everytime it is updated. It's effectively just writing the implementation twice, if you squint at it a bit.

Re: Stepping down as Mockito maintainer after ten years

#130

Post by fud101 »

BoiledCabbage wrote: post #55
wiseowise wrote: post #39

This is a good opportunity to ditch mocking and use fakes with adapters. Not only mocks create brittle tests that often test only the framework itself, but they do so in an order of magnitude slower way. Also, F Kotlin and their approach of "we'll reinvent the wheel with slightly different syntax and call it a new thing". Good riddance I say, let them implement their mockk, or whatever it is called, with ridiculous "…

The whole mocks, fakes and the rest were always a terrible idea. Although people didn't realize it st the time, they were a band-aid to try to make poorly architected code testable. 90% of the time, needing to use a mock is one of the clearest code warning smells you have of there being an issue in the design your code. It took a while, but the industry seems to be finally (although slowly) coming to this realization…

Ok, can someone explain this to someone with double digit iq? Is it validating the adapter idea or something else?
Post reply on HN