13 ms·

Stepping down as Mockito maintainer after ten years

283 points by saikatsg 10mo ago

ziofill 10mo ago
Beware of a supply chain attack
senko 10mo ago
For those, like me, who haven't heard of it: Mockito is the "most popular mocking framework for Java".
- ronnier 10mo ago
  It’s taken years off of my life dealing with the test mess people have made with it.
  - nsxwolf 10mo ago
    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.
    - pjc50 10mo ago
      What's specifically bad about Mockito here? Poor defaults for mocks?
      - eastbound 10mo ago
        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).
        blandflakes 10mo ago
        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.
        t-writescode 10mo ago
        One alternative to make code with typing styles in the Java way (as opposed to the Typescript or Go way) is to have a whole lot of custom interfaces and then you end up with a whole bunch of: doTheThing(foo: Fooable) { ... } when there's really only one Foo implementation in prod. It leads to (what feels like, to me) more code obfuscation in large projects, than the benefits that come out, at least for me. So Mockito and friends are a nice alternative to that. That is just my experience and opinion though, and there are definitely more valid or equally valid alternatives.
        blandflakes 10mo ago
        I don't think we have to choose. Naturally finding the "right division of labor" is as infinite as finding the "right level of abstraction", but I think the ideal situation is to strive toward code that is easy to test without having to introduce a lot of mocks or without infinite layers of abstraction.
      - xienze 10mo ago
        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.
        vips7L 10mo ago
        I've found that most of the time that if you need to mock, you probably just need to do an integration test.
        asa400 10mo ago
        I can’t concur with this enough. I’ve been on projects where mocking _literally made the project less reliable_ because people ended up “testing” against mocks that didn’t accurately reflect the behavior of the real APIs. It left us with functionality that wasn’t actually tested and resulted in real bugs and regressions that shipped. Mocking is one of these weird programmer pop-culture memetic viruses that spread in the early 2000s and achieved complete victory in the 2010s, like Agile and OOP, and now there are entire generations of devs who it’s not that they’re making a bad or a poorly argued choice, it’s that they literally don’t even know there are other ways of thinking about these problems because these ideas have sucked all the oxygen out of the room.
        rgoulter 10mo ago
        > like Agile and OOP Ha. I think there's room to argue "Agile" is a popular bastardisation of what's meant by "agile software development", and with "OOP" we got the lame Java interpretation rather than the sophisticated Smalltalk interpretation. -- Or I might think that these ideas aren't that good if their poor imitations win out over the "proper" ideas. With mocking.. I'm willing to be curious that there's some good/effective way of doing it. But the idea of "you're just testing that the compiler works" comes to mind.
        lisbbb 10mo ago
        Had my fill of both until I could not stand it anymore. So tired of the grifters--agile was sometimes good, but mostly a grift.
      - mrkeen 10mo ago
        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)
      - CSDude 10mo ago
        It allows you to mock the whole universe so it becomes a hammer instead of nicely designed functions, interfaces.
      - Sankozi 10mo ago
        People using it wrong. It definitely should not be that popular. 95% of times when I see it I consider it a tech debt. You should be using it in rare cases when you want to verify very complex code that needs to be working with strict requirements (like calling order is specified, or some calls cannot be made during execution of the method). Usually it is used for pointless unit tests of simple intermediary layers to test if call is delegated correctly to deeper layer. Those tests usually have negative value (they test very little but make any modification much harder).
    - mangodrunk 10mo ago
      Which is absurd that people use mocks considering the tests are supposed to help with refactoring but because of the mocks they can’t make a change without breaking the test.
    - the_arun 10mo ago
      I wish there are tests written to cover functionalities (& race conditions) instead of covering lines/branches.
- schumpeter 10mo ago
  It also translates to “small booger”, in Spanish, which always made me question who thought the name was a good idea over there.
  - Freak_NL 10mo ago
    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).
    - torben-friis 10mo ago
      >is likely to be weird in one language or another. But this name is weird in the specific language it’s imitating (both the -ito termination for diminutives and the drink on which I assumed the name is based are Spanish).
    - lisbbb 10mo ago
      Wasn't it a riff on "Mojito" which was a popular drink at the time?
      - OrangeMusic 10mo ago
        Mojitos aren't popular anymore?!
  - marinesebastian 10mo ago
    Actually, no. "small booger" would be _moquito_ in spanish.
    - schumpeter 10mo ago
      Fair. The spelling is off, but the pronunciation is the same.
      - kaoD 10mo ago
didip 10mo ago
As someone who is not in the Java world, why does Java need a mocking library? Interface based polymorphism is not enough?
- voidhorse 10mo ago
  Arguably it doesn't. Mocking is over used and you should just use a real implementation or distributor provided fake whenever possible.
- wetpaws 10mo ago
  [dead]
- totallykvothe 10mo ago
  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...
  - deepsun 10mo ago
    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.
    - wiseowise 10mo ago
      > But third-party IO is exactly the thing you'd want to mock. You write an adapter.
      - deepsun 10mo ago
        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".
gleenn 10mo ago
Sad to see an important project's core maintainer leave but their justification seems very understandable. It is sad so much of OSS is maintained by very few as they alluded to in the XKCD comment, an especially given they felt the JVM ecosystem was causing them pain with limited support or feedback possible. I think it is always a little irresponsible to cause a great deal of breakage and not be there to support those who you break downstream of your project.
krackers 10mo ago
>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?
- deleted 10mo ago
  [deleted]
- philipwhiuk 10mo ago
  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.
  - lisbbb 10mo ago
    I know!!!!!! I've been yelling about this for years how impossible to uplift JVM versions is because of how products were built! It's so crazy. Lots of obfuscated jars went unsupported after like Java 7.
- nitwit005 10mo ago
  It just means your test runs need to add the flag.
njitbew 10mo ago
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" not a satisfactory solution? Why do you even need a _dynamic_ agent; don't you know ahead of time exactly what agent you need when using Mockito? > While I fully understand the reasons that developers enjoy the feature richness of Kotlin as a programming language, its underlying implementation has significant downsides for projects like Mockito. Quite frankly, it's not fun to deal with. Why support Kotlin in the first place? If it's a pain to deal with, perhaps the Kotlin user base is better served by a Kotlin-specific mocking framework, maintained by people who enjoy working on those Kotlin-specific code paths?
- moribvndvs 10mo ago
  Mockito was indeed a poor fit for Kotlin. MockK is the one. Except I suppose for shops that have projects that mix Java and Kotlin and already have a Mockito tests.
- throwaw12 10mo ago
  > 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.
  - njitbew 10mo ago
    Sounds like a problem that the Mockito team created for themselves, and like a problem only they can solve.
CodesInChaos 10mo ago
What does Agent mean in this context? And what is "dynamic attachment of agents"?
- LoganDark 10mo ago
  A JVM agent is able to instrument and modify running JVM applications. Stuff like debugging, hot patching, etc rely on this. You used to be able to tell the JVM to listen on a port where you could connect debuggers (agents) dynamically at runtime, but that was deemed a security issue so now you can only declare specific agents at launch time through command-line flags.
- njitbew 10mo ago
  See https://openjdk.org/jeps/451 https://openjdk.org/jeps/451: JEP 451: Prepare to Disallow the Dynamic Loading of Agents, which has a lot of background on the topic.
- michaelt 10mo ago
  Tools for profiling, debugging, monitoring, thread analysis, and test coverage analysis can attach to the Java Virtual Machine (JVM) using the 'Tool Interface' If you've got a running java process on your local machine right now, you can use 'jconsole' to see the stack traces of all threads, inspect various memory statistics, trigger an immediate garbage collection or heap dump, and so on. And of course, if the tool is an instrumenting profiler - it needs the power to modify the running code, to insert its instrumentation. Obviously you need certain permissions on the host to do this - just like attaching gdb to a running process. This capability is used not just by for profiling, debugging and instrumentation but also by mockito to do its thing. Java 21 introduced a warning [1] saying this will be disabled in a forthcoming version, unless the process is started with '-XX:+EnableDynamicAgentLoading' - whereas previously it was enabled by default and '-XX:+DisableAttachMechanism' was used to disable it. The goal of doing this is "platform integrity" - preventing the attachment of debugging tools is useful in applications like DRM. [1] https://openjdk.org/jeps/451 https://openjdk.org/jeps/451
pron 10mo ago
> 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 declare its reliance on some invariant - e.g. that a certain class must not be extended, that a method can only be called by other methods in the same class, or that a field cannot be reassigned after being assigned in the constructor - and have the platform guarantee that the invariant is preserved globally throughout the lifetime of the program, no matter what other code does. What we call "memory safety" is an example of some invariants that have integrity. This is obviously important for security as it significantly reduces the blast radius of a vulnerability (some attacks that can be done in JS or Python cannot be done in Java), but it's also important for performance, as the compiler needs to know that certain optimisations preserve meaning. E.g. strings cannot be constant-folded if they can't be relied upon to be truly immutable. It's also important for backward-compatibility or "evolvability", as libraries cannot depend on internals that are not explicitly exposed as public APIs; libraries doing that was the cause of the migration pain from Java 8 to 9+, as lots of libraries depended on internal, non-API methods that have changed when the JDK's evolution started picking up steam. In Java, we've adopted a policy we call Integrity by Default (https://openjdk.org/jeps/8305968 https://openjdk.org/jeps/8305968), which means that code in one component can violate invariants established by code in another component only if the application is made aware of it and allows it. What isn't allowed is for a library - which could be some fourth-level dependency - to decide for itself at some point during the program's execution, without the application's knowledge, that actually strings in this program should be mutable. We were, and are, open to any ideas as long as this principle is preserved. Authors of components that do want to do such things find the policy inconvenient because their consumers need to do something extra that isn't required when using normal libraries. But this is a classic case of different users having conflicting requirements. No matter what you do, someone will be inconvenienced. We, the maintainers of the JDK, have opted for a solution that we believe minimises the pain and risk overall, when integrated over all users: Integrity is on by default, and components that wish to break it need an explicit configuration option to allow that. > built on a solid foundation with ByteBuddy ByteBuddy's author acknowledges that at least some aspects of ByteBuddy - and in particular the self-loading agent that Mockito used - weren't really a solid foundation, but now it should be: https://youtu.be/AzfhxgkBL9s?t=1843 https://youtu.be/AzfhxgkBL9s?t=1843. We are grateful to Rafael for explaining his needs to us so that we could find a way to satisfy them without violating Integrity by Default.
wiseowise 10mo ago
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 "fluent" syntax.
- BoiledCabbage 10mo ago
  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. And hopefully with it almost all of this can go away.
  - danparsonson 10mo ago
    How do you substitute for dependencies that you're not testing, or that you want to deliberately break?
    - bluGill 10mo ago
      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.
      - asa400 10mo ago
        I worked on a project where a dev wanted to mock out the database in tests "for performance, because the database is slow". I almost lost my shit. Even funnier, this was all hypothetical and yet taken as gospel. We hadn't even written the tests yet, so it was impossible to say whether they were slow or not. Nothing had been measured, no performance budget had been defined, no prototype of the supposedly slow tests had been written to demonstrate the point. We ended up writing - no joke - less than 100 tests total, almost all of which hit the database, including some full integration tests, and the entire test suite finished in a few seconds. I'm all for building in a way that respects performance as an engineering value, but we got lost somewhere along the way.
t-writescode 10mo ago
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.
- emodendroket 10mo ago
  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.
  - lisbbb 10mo ago
    I used it mainly because the code I inherited was untestable as written. I made it testable via those methods. Then it got refactored.
    - emodendroket 10mo ago
      Well sure you sometimes haven’t got much choice. But I’m talking about people write new code this way
- gerdesj 10mo ago
  "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.
xyzzy9563 10mo ago
>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 doubt his energy would be drained.
- __MatrixMan__ 10mo ago
  Disagree, its working for money that's draining. Extrinsic motivation is toxic to many things that might motivate an open source maintainer.
  - xyzzy9563 10mo ago
    What about paying your mortgage, food, utilities etc.? Or is that all supposed to come from savings or inheritance?
    - __MatrixMan__ 10mo ago
      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.
- p2detar 10mo ago
  I wouldn't make such a conclusion. I don't think there is any info about whether OP got financial incentives for his work or not. In fact, he posted on Mastodon, he's gonna be doing open source Rust work further on.
- philipwhiuk 10mo ago
  > 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.
mbfg 10mo ago
IMO mockito has a relatively good use experience. If you use MockitoExtension, especially, you write code that is relatively maintainable, and easy to mutate. The problem without MockitoExtension is you can throw all kinds of junk in there and it just sits there doing nothing, without you knowing it. Spy's on the other hand, are a pain in the neck. I think they should be good in theory, but in practice they are difficult, the debuggers really don't work correctly, setting breakpoints, stepping, etc, is just broken in many cases. Would love to know if this is just a difficult bug, or something that is baked into spying.
1a527dd5 10mo ago
Running open source _anything_ looks exhausting from the outside. I don't know why owners/maintainers show grace like this. For me; I would say I'm done and hand it over or just archive the repo. Hope Tim finds a measure of sanity after he steps down.
- hcfman 10mo ago
  I think showing grace was the right way to do things. It preserves the value of all the effort he put into it. When you work on things that long they are part of you. Like your baby, you don't toss them aside carelessly, it's painful to do that I'm sure. Well done for Tim for being one of those guys that worked so hard for others to benefit. Tim, you've done something you can be deeply proud of forever, no matter how it ended.
cletus 10mo ago
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.
- LgWoodenBadger 10mo ago
  “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.
  - saghm 10mo ago
exabrial 10mo ago
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.
bhawks 10mo ago
| 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.
- clanky 10mo ago
  The JDK team has advertised these changes for years. People who want to do wild & crazy dynamic stuff in their testing infrastructure still can, with a tiny amount of added setup. This is the correct tradeoff, vs having the JVM pessimistically unable to apply all sorts of optimizations because they never know when their users might have inadvertently opted into runtime shenanigans.
exabrial 10mo ago
TimvdLippe: You've done an incredible job. You have incredible ideas and vision. Just wanted to say thank you.
captainbland 10mo ago
> 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?
- wging 10mo ago
  I think the problem is that it's on his users to enable this flag, not something that can be done by Mockito automatically.
  - jhhh 10mo ago
    Most people want their test suite to pass. If they ugprade java and mockito prints out a message that they need to enabled '--some-flag' while running tests they're just going to add that flag to surefire in their pom. Seems like quite a small speedbump.
dave_sid 10mo ago
Mockito is fine if you know how to write tests. You can write bad tests with Mockito or many other frameworks if that’s what you do. You can even write bad tests while programming in Rust from high up in your ivory tower. You can write good tests also.
acedTrex 10mo ago
An excellent stepping down post, nothing more could be hoped for. Enjoy the next projects
lisbbb 10mo ago
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!
- EdwardDiego 10mo ago
  Pretty sure Powermock is dead in the water now, it did some pretty gnarly things (like patching `Object`) that flat out didn't work in later versions of Java. I (ironically enough) spent some time replacing usages of it in Kafka test code with Mockito because of this, IIRC there was only one situation where Mockito couldn't easily replace Powermock and I'm pretty sure it was mocking out a private static method, so the solution was to refactor the code under test so that you didn't need to mock a private static method to test it.
deleted 10mo ago
[deleted]
dingi 10mo ago
A lot of OSS burnout comes from a broken assumption: that publishing code creates an obligation. Historically, open source meant "here's code, use it if it helps, fix it if it breaks." No support contracts, no timelines, no moral duty. GitHub-era norms quietly inverted that into unpaid service work, with entitlement enforced socially ("be nice", "maintainers owe users"). Intrinsic motivation is the only sustainable fuel here. Once you start optimizing for users, stars, adoption, or goodwill, pressure accumulates and burnout is inevitable. When you build purely because the work itself is satisfying, stopping is always allowed, and that's what keeps projects healthy. Hard boundaries aren't hostility; they're corrective. Fewer projects would exist if more maintainers adopted them, but the ones that remain would be stronger, and companies would be forced to fund or own their forks honestly. Open source doesn't need more friendliness. It needs less obligation
ACV001 10mo ago
thank you for all you hard work!

283 points by saikatsg 10mo ago

ziofill 10mo ago

Beware of a supply chain attack

senko 10mo ago

For those, like me, who haven't heard of it: Mockito is the "most popular mocking framework for Java".

ronnier 10mo ago
It’s taken years off of my life dealing with the test mess people have made with it.
- nsxwolf 10mo ago
  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.
  - pjc50 10mo ago
    What's specifically bad about Mockito here? Poor defaults for mocks?
    - eastbound 10mo ago
      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).
      - blandflakes 10mo ago
        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.
        t-writescode 10mo ago
        One alternative to make code with typing styles in the Java way (as opposed to the Typescript or Go way) is to have a whole lot of custom interfaces and then you end up with a whole bunch of: doTheThing(foo: Fooable) { ... } when there's really only one Foo implementation in prod. It leads to (what feels like, to me) more code obfuscation in large projects, than the benefits that come out, at least for me. So Mockito and friends are a nice alternative to that. That is just my experience and opinion though, and there are definitely more valid or equally valid alternatives.
        blandflakes 10mo ago
        I don't think we have to choose. Naturally finding the "right division of labor" is as infinite as finding the "right level of abstraction", but I think the ideal situation is to strive toward code that is easy to test without having to introduce a lot of mocks or without infinite layers of abstraction.
    - xienze 10mo ago
      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.
      - vips7L 10mo ago
        I've found that most of the time that if you need to mock, you probably just need to do an integration test.
        asa400 10mo ago
        I can’t concur with this enough. I’ve been on projects where mocking _literally made the project less reliable_ because people ended up “testing” against mocks that didn’t accurately reflect the behavior of the real APIs. It left us with functionality that wasn’t actually tested and resulted in real bugs and regressions that shipped. Mocking is one of these weird programmer pop-culture memetic viruses that spread in the early 2000s and achieved complete victory in the 2010s, like Agile and OOP, and now there are entire generations of devs who it’s not that they’re making a bad or a poorly argued choice, it’s that they literally don’t even know there are other ways of thinking about these problems because these ideas have sucked all the oxygen out of the room.
        rgoulter 10mo ago
        > like Agile and OOP Ha. I think there's room to argue "Agile" is a popular bastardisation of what's meant by "agile software development", and with "OOP" we got the lame Java interpretation rather than the sophisticated Smalltalk interpretation. -- Or I might think that these ideas aren't that good if their poor imitations win out over the "proper" ideas. With mocking.. I'm willing to be curious that there's some good/effective way of doing it. But the idea of "you're just testing that the compiler works" comes to mind.
        lisbbb 10mo ago
        Had my fill of both until I could not stand it anymore. So tired of the grifters--agile was sometimes good, but mostly a grift.
    - mrkeen 10mo ago
      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)
    - CSDude 10mo ago
      It allows you to mock the whole universe so it becomes a hammer instead of nicely designed functions, interfaces.
    - Sankozi 10mo ago
      People using it wrong. It definitely should not be that popular. 95% of times when I see it I consider it a tech debt. You should be using it in rare cases when you want to verify very complex code that needs to be working with strict requirements (like calling order is specified, or some calls cannot be made during execution of the method). Usually it is used for pointless unit tests of simple intermediary layers to test if call is delegated correctly to deeper layer. Those tests usually have negative value (they test very little but make any modification much harder).
  - mangodrunk 10mo ago
    Which is absurd that people use mocks considering the tests are supposed to help with refactoring but because of the mocks they can’t make a change without breaking the test.
  - the_arun 10mo ago
    I wish there are tests written to cover functionalities (& race conditions) instead of covering lines/branches.
schumpeter 10mo ago
It also translates to “small booger”, in Spanish, which always made me question who thought the name was a good idea over there.
- Freak_NL 10mo ago
  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).
  - torben-friis 10mo ago
    >is likely to be weird in one language or another. But this name is weird in the specific language it’s imitating (both the -ito termination for diminutives and the drink on which I assumed the name is based are Spanish).
  - lisbbb 10mo ago
    Wasn't it a riff on "Mojito" which was a popular drink at the time?
    - OrangeMusic 10mo ago
      Mojitos aren't popular anymore?!
- marinesebastian 10mo ago
  Actually, no. "small booger" would be _moquito_ in spanish.
  - schumpeter 10mo ago
    Fair. The spelling is off, but the pronunciation is the same.
    - kaoD 10mo ago

didip 10mo ago

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

voidhorse 10mo ago
Arguably it doesn't. Mocking is over used and you should just use a real implementation or distributor provided fake whenever possible.
wetpaws 10mo ago
[dead]
totallykvothe 10mo ago
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...
- deepsun 10mo ago
  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.
  - wiseowise 10mo ago
    > But third-party IO is exactly the thing you'd want to mock. You write an adapter.
    - deepsun 10mo ago
      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".

gleenn 10mo ago

Sad to see an important project's core maintainer leave but their justification seems very understandable. It is sad so much of OSS is maintained by very few as they alluded to in the XKCD comment, an especially given they felt the JVM ecosystem was causing them pain with limited support or feedback possible. I think it is always a little irresponsible to cause a great deal of breakage and not be there to support those who you break downstream of your project.

krackers 10mo ago

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

deleted 10mo ago
[deleted]
philipwhiuk 10mo ago
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.
- lisbbb 10mo ago
  I know!!!!!! I've been yelling about this for years how impossible to uplift JVM versions is because of how products were built! It's so crazy. Lots of obfuscated jars went unsupported after like Java 7.
nitwit005 10mo ago
It just means your test runs need to add the flag.

njitbew 10mo ago

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" not a satisfactory solution? Why do you even need a _dynamic_ agent; don't you know ahead of time exactly what agent you need when using Mockito? > While I fully understand the reasons that developers enjoy the feature richness of Kotlin as a programming language, its underlying implementation has significant downsides for projects like Mockito. Quite frankly, it's not fun to deal with. Why support Kotlin in the first place? If it's a pain to deal with, perhaps the Kotlin user base is better served by a Kotlin-specific mocking framework, maintained by people who enjoy working on those Kotlin-specific code paths?

moribvndvs 10mo ago
Mockito was indeed a poor fit for Kotlin. MockK is the one. Except I suppose for shops that have projects that mix Java and Kotlin and already have a Mockito tests.
throwaw12 10mo ago
> 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.
- njitbew 10mo ago
  Sounds like a problem that the Mockito team created for themselves, and like a problem only they can solve.

CodesInChaos 10mo ago

What does Agent mean in this context? And what is "dynamic attachment of agents"?

LoganDark 10mo ago
A JVM agent is able to instrument and modify running JVM applications. Stuff like debugging, hot patching, etc rely on this. You used to be able to tell the JVM to listen on a port where you could connect debuggers (agents) dynamically at runtime, but that was deemed a security issue so now you can only declare specific agents at launch time through command-line flags.
njitbew 10mo ago
See https://openjdk.org/jeps/451 https://openjdk.org/jeps/451: JEP 451: Prepare to Disallow the Dynamic Loading of Agents, which has a lot of background on the topic.
michaelt 10mo ago
Tools for profiling, debugging, monitoring, thread analysis, and test coverage analysis can attach to the Java Virtual Machine (JVM) using the 'Tool Interface' If you've got a running java process on your local machine right now, you can use 'jconsole' to see the stack traces of all threads, inspect various memory statistics, trigger an immediate garbage collection or heap dump, and so on. And of course, if the tool is an instrumenting profiler - it needs the power to modify the running code, to insert its instrumentation. Obviously you need certain permissions on the host to do this - just like attaching gdb to a running process. This capability is used not just by for profiling, debugging and instrumentation but also by mockito to do its thing. Java 21 introduced a warning [1] saying this will be disabled in a forthcoming version, unless the process is started with '-XX:+EnableDynamicAgentLoading' - whereas previously it was enabled by default and '-XX:+DisableAttachMechanism' was used to disable it. The goal of doing this is "platform integrity" - preventing the attachment of debugging tools is useful in applications like DRM. [1] https://openjdk.org/jeps/451 https://openjdk.org/jeps/451

pron 10mo ago

> 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 declare its reliance on some invariant - e.g. that a certain class must not be extended, that a method can only be called by other methods in the same class, or that a field cannot be reassigned after being assigned in the constructor - and have the platform guarantee that the invariant is preserved globally throughout the lifetime of the program, no matter what other code does. What we call "memory safety" is an example of some invariants that have integrity. This is obviously important for security as it significantly reduces the blast radius of a vulnerability (some attacks that can be done in JS or Python cannot be done in Java), but it's also important for performance, as the compiler needs to know that certain optimisations preserve meaning. E.g. strings cannot be constant-folded if they can't be relied upon to be truly immutable. It's also important for backward-compatibility or "evolvability", as libraries cannot depend on internals that are not explicitly exposed as public APIs; libraries doing that was the cause of the migration pain from Java 8 to 9+, as lots of libraries depended on internal, non-API methods that have changed when the JDK's evolution started picking up steam. In Java, we've adopted a policy we call Integrity by Default (https://openjdk.org/jeps/8305968 https://openjdk.org/jeps/8305968), which means that code in one component can violate invariants established by code in another component only if the application is made aware of it and allows it. What isn't allowed is for a library - which could be some fourth-level dependency - to decide for itself at some point during the program's execution, without the application's knowledge, that actually strings in this program should be mutable. We were, and are, open to any ideas as long as this principle is preserved. Authors of components that do want to do such things find the policy inconvenient because their consumers need to do something extra that isn't required when using normal libraries. But this is a classic case of different users having conflicting requirements. No matter what you do, someone will be inconvenienced. We, the maintainers of the JDK, have opted for a solution that we believe minimises the pain and risk overall, when integrated over all users: Integrity is on by default, and components that wish to break it need an explicit configuration option to allow that. > built on a solid foundation with ByteBuddy ByteBuddy's author acknowledges that at least some aspects of ByteBuddy - and in particular the self-loading agent that Mockito used - weren't really a solid foundation, but now it should be: https://youtu.be/AzfhxgkBL9s?t=1843 https://youtu.be/AzfhxgkBL9s?t=1843. We are grateful to Rafael for explaining his needs to us so that we could find a way to satisfy them without violating Integrity by Default.

wiseowise 10mo ago

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 "fluent" syntax.

BoiledCabbage 10mo ago
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. And hopefully with it almost all of this can go away.
- danparsonson 10mo ago
  How do you substitute for dependencies that you're not testing, or that you want to deliberately break?
  - bluGill 10mo ago
    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.
    - asa400 10mo ago
      I worked on a project where a dev wanted to mock out the database in tests "for performance, because the database is slow". I almost lost my shit. Even funnier, this was all hypothetical and yet taken as gospel. We hadn't even written the tests yet, so it was impossible to say whether they were slow or not. Nothing had been measured, no performance budget had been defined, no prototype of the supposedly slow tests had been written to demonstrate the point. We ended up writing - no joke - less than 100 tests total, almost all of which hit the database, including some full integration tests, and the entire test suite finished in a few seconds. I'm all for building in a way that respects performance as an engineering value, but we got lost somewhere along the way.

t-writescode 10mo ago

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.

emodendroket 10mo ago
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.
- lisbbb 10mo ago
  I used it mainly because the code I inherited was untestable as written. I made it testable via those methods. Then it got refactored.
  - emodendroket 10mo ago
    Well sure you sometimes haven’t got much choice. But I’m talking about people write new code this way
gerdesj 10mo ago
"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.

xyzzy9563 10mo ago

>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 doubt his energy would be drained.

__MatrixMan__ 10mo ago
Disagree, its working for money that's draining. Extrinsic motivation is toxic to many things that might motivate an open source maintainer.
- xyzzy9563 10mo ago
  What about paying your mortgage, food, utilities etc.? Or is that all supposed to come from savings or inheritance?
  - __MatrixMan__ 10mo ago
    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.
p2detar 10mo ago
I wouldn't make such a conclusion. I don't think there is any info about whether OP got financial incentives for his work or not. In fact, he posted on Mastodon, he's gonna be doing open source Rust work further on.
philipwhiuk 10mo ago
> 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.

mbfg 10mo ago

IMO mockito has a relatively good use experience. If you use MockitoExtension, especially, you write code that is relatively maintainable, and easy to mutate. The problem without MockitoExtension is you can throw all kinds of junk in there and it just sits there doing nothing, without you knowing it. Spy's on the other hand, are a pain in the neck. I think they should be good in theory, but in practice they are difficult, the debuggers really don't work correctly, setting breakpoints, stepping, etc, is just broken in many cases. Would love to know if this is just a difficult bug, or something that is baked into spying.

1a527dd5 10mo ago

Running open source _anything_ looks exhausting from the outside. I don't know why owners/maintainers show grace like this. For me; I would say I'm done and hand it over or just archive the repo. Hope Tim finds a measure of sanity after he steps down.

hcfman 10mo ago
I think showing grace was the right way to do things. It preserves the value of all the effort he put into it. When you work on things that long they are part of you. Like your baby, you don't toss them aside carelessly, it's painful to do that I'm sure. Well done for Tim for being one of those guys that worked so hard for others to benefit. Tim, you've done something you can be deeply proud of forever, no matter how it ended.

cletus 10mo ago

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.

LgWoodenBadger 10mo ago
“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.
- saghm 10mo ago

exabrial 10mo ago

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.

bhawks 10mo ago

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

clanky 10mo ago
The JDK team has advertised these changes for years. People who want to do wild & crazy dynamic stuff in their testing infrastructure still can, with a tiny amount of added setup. This is the correct tradeoff, vs having the JVM pessimistically unable to apply all sorts of optimizations because they never know when their users might have inadvertently opted into runtime shenanigans.

exabrial 10mo ago

TimvdLippe: You've done an incredible job. You have incredible ideas and vision. Just wanted to say thank you.

captainbland 10mo ago

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

wging 10mo ago
I think the problem is that it's on his users to enable this flag, not something that can be done by Mockito automatically.
- jhhh 10mo ago
  Most people want their test suite to pass. If they ugprade java and mockito prints out a message that they need to enabled '--some-flag' while running tests they're just going to add that flag to surefire in their pom. Seems like quite a small speedbump.

dave_sid 10mo ago

Mockito is fine if you know how to write tests. You can write bad tests with Mockito or many other frameworks if that’s what you do. You can even write bad tests while programming in Rust from high up in your ivory tower. You can write good tests also.

acedTrex 10mo ago

An excellent stepping down post, nothing more could be hoped for. Enjoy the next projects

lisbbb 10mo ago

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!

EdwardDiego 10mo ago
Pretty sure Powermock is dead in the water now, it did some pretty gnarly things (like patching `Object`) that flat out didn't work in later versions of Java. I (ironically enough) spent some time replacing usages of it in Kafka test code with Mockito because of this, IIRC there was only one situation where Mockito couldn't easily replace Powermock and I'm pretty sure it was mocking out a private static method, so the solution was to refactor the code under test so that you didn't need to mock a private static method to test it.

deleted 10mo ago

[deleted]

dingi 10mo ago

A lot of OSS burnout comes from a broken assumption: that publishing code creates an obligation. Historically, open source meant "here's code, use it if it helps, fix it if it breaks." No support contracts, no timelines, no moral duty. GitHub-era norms quietly inverted that into unpaid service work, with entitlement enforced socially ("be nice", "maintainers owe users"). Intrinsic motivation is the only sustainable fuel here. Once you start optimizing for users, stars, adoption, or goodwill, pressure accumulates and burnout is inevitable. When you build purely because the work itself is satisfying, stopping is always allowed, and that's what keeps projects healthy. Hard boundaries aren't hostility; they're corrective. Fewer projects would exist if more maintainers adopted them, but the ones that remain would be stronger, and companies would be forced to fund or own their forks honestly. Open source doesn't need more friendliness. It needs less obligation

ACV001 10mo ago

thank you for all you hard work!