11–20 of 220 posts
As someone who is not in the Java world, why does Java need a mocking library? Interface based polymorphism is not enough?
As someone who is not in the Java world, why does Java need a mocking library? Interface based polymorphism is not enough?
As someone who is not in the Java world, why does Java need a mocking library? Interface based polymorphism is not enough?
At the moment I can't see anything Mokckito gives that you technically couldn't implement yourself via subclassing and overriding, but it'd be a lot of boilerplate to proxy things and record the arguments.
As someone who is not in the Java world, why does Java need a mocking library? Interface based polymorphism is not enough?
For those, like me, who haven't heard of it: Mockito is the "most popular mocking framework for Java".
> 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?
For those, like me, who haven't heard of it: Mockito is the "most popular mocking framework for Java".
It also translates to “small booger”, in Spanish, which always made me question who thought the name was a good idea over there.
As someone who is not in the Java world, why does Java need a mocking library? Interface based polymorphism is not enough?
Mocks make it easy to record and assert on method invocations. Additionally spys (instance mocks) are really useful when you need to forward to the real method or rely on some state. At the moment I can't see anything Mokckito gives that you technically couldn't implement yourself via subclassing and overriding, but it'd be a lot of boilerplate to proxy things and record the arguments.
Earlier quoted context omitted.
Mocks make it easy to record and assert on method invocations. Additionally spys (instance mocks) are really useful when you need to forward to the real method or rely on some state. At the moment I can't see anything Mokckito gives that you technically couldn't implement yourself via subclassing and overriding, but it'd be a lot of boilerplate to proxy things and record the arguments.
Subclasing and overriding is not a good idea. There is no compilation failure if you forget to override a function which can lead to flakey tests at best and prod data impact at worst.
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" n…