Stepping down as Mockito maintainer after ten years • Hacker News Board

Re: Stepping down as Mockito maintainer after ten years

#41

Post by 0x1ceb00da » Sun, Dec 28, 2025, 10:28 PM UTC

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…

> some attacks that can be done in JS or Python cannot be done in Java

Examples?

Re: Stepping down as Mockito maintainer after ten years

#42

Post by sunnybeetroot » Sun, Dec 28, 2025, 10:32 PM UTC

senbrow wrote: post #38

sunnybeetroot wrote: post #21

Earlier quoted context omitted.

Credentials end up existing in prod because the person used Mochito and didn’t override the function for providing credentials :’c

Credentials should only be provided at the application root, which is going to be a different root for a test harness. Mockito shouldn't change whether or not this is possible; the code shouldn't have the prod creds (or any external resource references) hard coded in the compiled bytecode.

I totally agree, I’m being tongue in cheek, but given how poor some codebases can be, the more precautions the better ie compilation failures on non-mocked functions.

Re: Stepping down as Mockito maintainer after ten years

#43

Post by wiseowise » Sun, Dec 28, 2025, 10:32 PM UTC

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?

It doesn't. But good luck teaching hordes of enterprise "developers".

Re: Stepping down as Mockito maintainer after ten years

#44

Post by wiseowise » Sun, Dec 28, 2025, 10:33 PM UTC

deepsun wrote: post #25

totallykvothe wrote: post #9

Earlier quoted context omitted.

Mockito allows one to write mocks in tests for code that doesn't use dependency injection and isn't properly testable in any other way. On the one hand, you should just design things to be testable from the start. On the other... I'm already working in this codebase with 20 years of legacy untestable design...

Google API libraries mark every class as "final" so it's not trivial to mock-extend it for tests. But third-party IO is exactly the thing you'd want to mock. Probably because they zealously followed "Effective Java" book.

> But third-party IO is exactly the thing you'd want to mock.

You write an adapter.

Re: Stepping down as Mockito maintainer after ten years

#45

Post by pron » Sun, Dec 28, 2025, 10:34 PM UTC

0x1ceb00da wrote: post #41

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…

> some attacks that can be done in JS or Python cannot be done in Java Examples?

In September there was a supply-chain attack on NPM where the payload code injected hooks into the DOM API. Changing the behaviour of encapsulated components, like Java's standard library, is not possible now without the application explicitly allowing code to break the integrity of the encapsulated component.

Re: Stepping down as Mockito maintainer after ten years

#46

Post by eastbound » Sun, Dec 28, 2025, 10:36 PM UTC

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?

I’ll answer: Nothing specific to Mockito, it happens in every language. Tests “solidify” code which makes refactoring hard. And yet, after refactoring, one can be happy to have tests to check whether there is any regression.

Testing is hard. I’ve tried with AI today: No, it is still not capable of handling that kind of (straightforward) task (Using Claude).

Re: Stepping down as Mockito maintainer after ten years

#47

Post by blandflakes » Sun, Dec 28, 2025, 10:41 PM UTC

eastbound wrote: post #46

pjc50 wrote: post #40

Earlier quoted context omitted.

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

I’ll answer: Nothing specific to Mockito, it happens in every language. Tests “solidify” code which makes refactoring hard. And yet, after refactoring, one can be happy to have tests to check whether there is any regression. Testing is hard. I’ve tried with AI today: No, it is still not capable of handling that kind of (straightforward) task (Using Claude).

They also encourage/enable code that is less testable. If you use mockito to get your fake responses/assertions where you need them, you don't have to think about your class's dependencies to make your code testable and therefore better decomposed. I don't even do TDD, but I still find that thinking about how I'd test a class guides me toward better-factored code.

Re: Stepping down as Mockito maintainer after ten years

#48

Post by dhosek » Sun, Dec 28, 2025, 10:48 PM UTC

kaoD wrote: post #34

schumpeter wrote: post #30

Earlier quoted context omitted.

Fair. The spelling is off, but the pronunciation is the same.

I'm Spanish and subconsciously pronounced the library as MOCKito, as opposed to moQUIto.

I’m bilingual(ish) and while I’ve always pronounced it MOCKito, I think I may start pronouncing it moQUIto instead now.

Re: Stepping down as Mockito maintainer after ten years

#49

Post by t-writescode » Sun, Dec 28, 2025, 10:55 PM UTC

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 useful than MockK, though I have heard MockK is the "one that's better for Kotlin". It's mostly just vocabulary changes for me, the user.

I'm going to have to monitor Mockito's future and see if I'll need to swap to MockK at some point if Mockito becomes unmaintained.

Re: Stepping down as Mockito maintainer after ten years

#50

Post by deepsun » Sun, Dec 28, 2025, 10:57 PM UTC

wiseowise wrote: post #44

deepsun wrote: post #25

Earlier quoted context omitted.

Google API libraries mark every class as "final" so it's not trivial to mock-extend it for tests. But third-party IO is exactly the thing you'd want to mock. Probably because they zealously followed "Effective Java" book.

> But third-party IO is exactly the thing you'd want to mock. You write an adapter.

No, some other library classes accept only their own, not my adapter.

Not mentioning of course needless copy-pasting dosens of members in the adapter. And it must be in prod code, not tests, even though it's documentation would say "Adapter for X, exists only for tests, to be able to mock X".