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

181–190 of 220 posts

Re: Stepping down as Mockito maintainer after ten years

#181

Post by mangodrunk »

danparsonson wrote: post #103
mangodrunk wrote: post #93

Earlier quoted context omitted.

Why substitute dependencies? Is the isolation worth it?

For the same reason you isolate variables in a scientific experiment; to ensure you're controlling the test that you're running, and not accidentally testing something else. To easily simulate failure cases, a range of possible inputs, bad data etc. To make the testing process faster when you have hundreds or thousands of tests, running on multiple builds simultaneously across an organisation. Off the top of my head…

I don’t think it’s worth doing that, and comparing it to scientific experiments doesn’t really apply.

You can do all that without mocks as well.

Making the tests run faster at the expense of better tests seems counterproductive.

Now you should think of reasons why you should not isolate.

Re: Stepping down as Mockito maintainer after ten years

#182

Post by lisbbb »

philipwhiuk wrote: post #73
krackers wrote: post #8

>Mockito 5 shipped a breaking change where its main artifact is now an agent. That's because starting JVM 22, the previous so-called "dynamic attachment of agents" is put behind a flag Wouldn't this hold back enterprise adoption, the same way breaking changes meant that Java 8 was widely used for a long time?

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.

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.

Re: Stepping down as Mockito maintainer after ten years

#184

Post by clanky »

bhawks wrote: post #83

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

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.

Re: Stepping down as Mockito maintainer after ten years

#185

Post by Larrikin »

gf000 wrote: post #168
vips7L wrote: post #95

Earlier quoted context omitted.

I'm not sure Kotlin is a hack, but it's growth is directly related to Java not being able to deliver on simple features that would help the day to day lives of developers. So I also can't blame anyone for moving on from the language. I get frustrated with it all the time, especially when Kotlin shows that some feature could work perfectly fine. Here are some examples that have hit the graveyard: It's been 2 years sin…

Sure there are pain points in Java, but I definitely wouldn't want the language to introduce 15 new features each having only a tiny benefit. Based on your other comment you prefer "fat" languages like kotlin and C# - and that's fair. I find languages with less, but more powerful features far more elegant and while Java has its fair share of historic warts, modern additions are made in a very smart way. E.g. switch e…

What can switches finally do that when can't? Other than the terrible fall through behavior?

When used as a different way of writing an if else if can be a code smell. When used with an exhaustive list of an enum or sealed class prevents bugs in production.

Re: Stepping down as Mockito maintainer after ten years

#186

Post by gf000 »

Larrikin wrote: post #185
gf000 wrote: post #168

Earlier quoted context omitted.

Sure there are pain points in Java, but I definitely wouldn't want the language to introduce 15 new features each having only a tiny benefit. Based on your other comment you prefer "fat" languages like kotlin and C# - and that's fair. I find languages with less, but more powerful features far more elegant and while Java has its fair share of historic warts, modern additions are made in a very smart way. E.g. switch e…

What can switches finally do that when can't? Other than the terrible fall through behavior? When used as a different way of writing an if else if can be a code smell. When used with an exhaustive list of an enum or sealed class prevents bugs in production.

Switch expressions don't do fall through. They are proper ML-like pattern matching.

Re: Stepping down as Mockito maintainer after ten years

#187

Post by krzyk »

vips7L wrote: post #176
gf000 wrote: post #168

Earlier quoted context omitted.

Sure there are pain points in Java, but I definitely wouldn't want the language to introduce 15 new features each having only a tiny benefit. Based on your other comment you prefer "fat" languages like kotlin and C# - and that's fair. I find languages with less, but more powerful features far more elegant and while Java has its fair share of historic warts, modern additions are made in a very smart way. E.g. switch e…

I’m sorry, but null restricted types, string templates, basic json support, and fixing the broken exception system isn’t “fat”. They’re the basics of a functioning language.

Handling JSON as a basics for language? Really? null restricted type will come with valhalla, string templates had a try, but people complained and they withdrawn them after 2 preview iterations. Not sure what issue people had with them and what issues maintainers noticed.

What do you mean by broken exception system?

Java is not a small language that you can throw features around, they have to take into consideration final goal of it and decades of development.

Re: Stepping down as Mockito maintainer after ten years

#188

Post by krzyk »

Larrikin wrote: post #111
WD-42 wrote: 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…

> Scala was the hack

> Kotlin designers evaluated language

Well, I like scala, and most of the time I understand it, but I can't say the same with Kotlin. I would say quite the opposite is true.

Re: Stepping down as Mockito maintainer after ten years

#189

Post by tizzy »

throwaway7375 wrote: post #51
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?

Before Mockito, it was common (where I worked) to create an interface just to support testing. This is an anti-pattern in my opinion. To create interfaces just for testing complicates the code and it is one of my pet peeves. It also encourages the factory pattern. I prefer Mockito's approach.

It’s definitely a bit annoying and verbose in Java but I think creating an interface to support testing is a net positive. That interface is the specification of what that concrete class requires it’s dependencies to do.

I think all the dependencies of a class should define behaviour not implementation so it’s not tightly coupled and can be modified in the future. If you have a class that injects LookUpService, why not put an interface LookUpper in front of it? It’s a layer of indirection but we have IDEs now and reading the interface should be easier or at least provide context.

Re: Stepping down as Mockito maintainer after ten years

#190

Post by deepsun »

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.

I think it's easier to unpack/remove-"final"/re-compile the library .jar during the build time. Will be more stable to any changes than an adapter.
Post reply on HN