Live data from Hacker News

Stepping down as Mockito maintainer after ten years

github.com

111–120 of 220 posts

Re: Stepping down as Mockito maintainer after ten years

#111
post #80

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.

Kotlin is a thoughtful language that is a joy to write.

Java was stagnant and ripe for being kicked off the top.

Scala was the hack that showed why Java was starting to suck but Scala suffered from no direction. Every single idea a PhD ever had was implemented in the language with no thought other than it seems cool to be able to do that too. Which is why all the Scala codebases fell apart, because you could write anything, anyway you want, and it was impossible to maintain without extremely strict guidelines on what parts of the language you were allowed to use. Also the build times were atrocious.

Kotlin designers evaluated language features across the ecosystem and chose what made sense to make Java better when it came out and now has easily surpassed Java. They are still thoughtful in what they choose to add to the language and it is now very powerful. However they smartly imitate Python by having clear guidelines on what choices you should be making when writing code so that other developers can easily dive in.

Re: Stepping down as Mockito maintainer after ten years

#112
post #68
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.

Mocking and integration tests are not mutually exclusive. I often use mocks in my integration tests. Some things can be integration tested, some things can't. Sone things you just need to mock.

Re: Stepping down as Mockito maintainer after ten years

#113
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…

Mockito, in every case I had to use it, was a last resort because a third party library didnt lend itself to mocking, or you were bringing legacy code under test and using it long enough to refactor it out.

It should never be the first tool. But when you need it, it’s very useful.

Re: Stepping down as Mockito maintainer after ten years

#114
Hey, fwiw, thank you for all of your hard work! Mockito and Powermock helped me be a big hero at one company I worked for 2011-2014. Before I arrived as a tech lead there, they had ZERO tests. The QA cycle was weeks, even months long. I instituted a whole new regime of unit and intergration testing for all the applications I was responsible for. Within one release cycle, the bug counts fell to nearly zero and the QA cycle basically became a verification step because there were no more bugs. The only way I was able to pull that off was using mocking and some clever powermock hacks because the code was otherwise untestable and thus un-refactorable. So, thanks!

Re: Stepping down as Mockito maintainer after ten years

#115
post #80

Earlier quoted context omitted.

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.

Kotlin is a thoughtful language that is a joy to write. Java was stagnant and ripe for being kicked off the top. Scala was the hack that showed why Java was starting to suck but Scala suffered from no direction. Every single idea a PhD ever had was implemented in the language with no thought other than it seems cool to be able to do that too. Which is why all the Scala codebases fell apart, because you could write an…

I liked Groovy, but Kotlin was the better successor. Scala was beyond ridiculous as far as learning curve--crazy language. I always thought Java sucked and I spent far too much time working with Java (because money) and having to deal with framework on top of framework as well as all those idiotic design patterns that seemed so important only for me to realize years later that it was all basically a waste because OOP itself is a waste. I was writing better code in Python and Go five years ago without needing those all-important design patterns (okay, a few still translate). I just didn't know it at the time how horrible the situation was in Java. In hindsight, everything about Java was someone's money grab that I was dealing with. Mockito did help me a lot through those times, but I wish I had never gone through them at all!

Re: Stepping down as Mockito maintainer after ten years

#116

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.

I used it mainly because the code I inherited was untestable as written. I made it testable via those methods. Then it got refactored.

Re: Stepping down as Mockito maintainer after ten years

#117
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?

Re: Stepping down as Mockito maintainer after ten years

#118
post #32
post #3

Earlier quoted context omitted.

It’s taken years off of my life dealing with the test mess people have made with it.

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.

I wish there are tests written to cover functionalities (& race conditions) instead of covering lines/branches.

Re: Stepping down as Mockito maintainer after ten years

#119
post #85

Earlier quoted context omitted.

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 origi…

> 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.

So this change doesn't allow an empty result set, something that is no longer allowed by the new implementation but was allowed previously. Isn't that the sort of breaking change you want your regression tests to catch?

Re: Stepping down as Mockito maintainer after ten years

#120
post #115

Earlier quoted context omitted.

Kotlin is a thoughtful language that is a joy to write. Java was stagnant and ripe for being kicked off the top. Scala was the hack that showed why Java was starting to suck but Scala suffered from no direction. Every single idea a PhD ever had was implemented in the language with no thought other than it seems cool to be able to do that too. Which is why all the Scala codebases fell apart, because you could write an…

I liked Groovy, but Kotlin was the better successor. Scala was beyond ridiculous as far as learning curve--crazy language. I always thought Java sucked and I spent far too much time working with Java (because money) and having to deal with framework on top of framework as well as all those idiotic design patterns that seemed so important only for me to realize years later that it was all basically a waste because OOP…

I still miss dependency injection in Python
Post reply on HN