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

211–220 of 220 posts

Re: Stepping down as Mockito maintainer after ten years

#211

Post by asa400 »

ben_w wrote: post #209
rgoulter wrote: post #106

Earlier quoted context omitted.

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

For OOP, I'd say the issue isn't so much that it's not useful (it is very useful), but rather that it was treated as "common sense, the only way to do it". Sometimes the right tool for the job is objects, sometimes it's functional, sometimes you do want encapsulation but it's better as structs and using composition over inheritance. When everything looks like a `class Hammer extends Tool`…

Agreed - I like your phrasing of it. There are some good ideas in OOP. I don't know that I'd go as far as to credit OOP for those ideas, but things like polymorphism and encapsulation can be very useful. What I objected to was, as you said, OOP became "the only way to do it". It became a dogma. I was very happy when functional programming started to break through and show that there were other ways that were not only viable, but often better.

Re: Stepping down as Mockito maintainer after ten years

#212

Post by danparsonson »

mangodrunk wrote: post #208
danparsonson wrote: post #199

Earlier quoted context omitted.

> I don’t think it’s worth doing that OK; it's your choice to do what you think is right. > and comparing it to scientific experiments doesn’t really apply. Why not? I think it's a fairly apt comparison; you have a theory ("this piece of code does the following things"), and write tests to prove it. > You can do all that without mocks as well. OK, but mocks make it easier and cleaner - so why wouldn't I do that? > Ma…

I don’t want to take too much of a tangent, but in scientific studies, you are trying to understand some phenomena, and isolating variables can help with very complex things. A test is typically not that complex. Another example is the use of animals in testing medicine, it can help but it obviously would be much better to test directly on humans but we don’t for good reason. Your position is reasonable and I do thin…

> in scientific studies, you are trying to understand some phenomena, and isolating variables can help with very complex things.

Not to labour the point here, but no, the primary reason you isolate variables in a scientific experiment is that you want to ensure you're only testing the thing you intend to test. A medical study is a good example - you want to be sure that the effect you observed was due to the drug you're testing, and not some unrelated lifestyle factor.

Thanks for sharing your views on the rest; there was just one thing I wanted to expand on:

> Now let’s say you mock something in your function. Let’s say you make a change to that but the input and output are the exact same. Now you have to update your test.

I think the scenario you're describing here is: a function's dependencies have changed, but the inputs and outputs of that function have not; therefore even though the behaviour is the same, the tests still need to be updated. Is that right? In which case I would say: of course you need to update the tests - the dependencies have changed and therefore the behaviour of the function depends on different things and you need to model the behaviour of those new things in order to properly test the original function. To me this objection only holds if you are mainly focussed on code coverage; however, to me, good testing exercises the same code paths in multiple different ways to stress the code and ensure that the results are correct given all possible inputs. The dependencies of a function are also inputs of a kind.

Re: Stepping down as Mockito maintainer after ten years

#213

Post by danparsonson »

bluGill wrote: post #210
danparsonson wrote: post #203

Earlier quoted context omitted.

I'm sorry, I don't understand what you mean. You seem to say it's not worth writing a lot of tests, but then you talk about tests breaking due to bad changes - if you don't write those tests in the first place, then how do you get into that situation? I didn't word my earlier comment very well - I don't mean to advocate for 100% coverage, which I personally think is a waste of time at best, and a false comfort at wor…

Let me put it a different way: what is a unit? i have concluded a unit needs to be large. Not a single class or function but a large collection of them. When 'archtecture astronaughts' draw their boxes they ar drawing units. Often thousands of functions belong to a unit. even then though often it is easier to use the real other unit than a test double.

You can make your own definition of unit if you like, but the usual definition is the smallest whole piece of something - a unit of currency, a unit of measure, etc.

If your unit is thousands of functions wide then you have a monolith, and there are widely discussed reasons why we try to avoid those.

Re: Stepping down as Mockito maintainer after ten years

#214

Post by danparsonson »

bluGill wrote: post #206
danparsonson wrote: post #203

Earlier quoted context omitted.

I'm sorry, I don't understand what you mean. You seem to say it's not worth writing a lot of tests, but then you talk about tests breaking due to bad changes - if you don't write those tests in the first place, then how do you get into that situation? I didn't word my earlier comment very well - I don't mean to advocate for 100% coverage, which I personally think is a waste of time at best, and a false comfort at wor…

Write a lot of tests - mostly integration. Unit tests have proven more harmful than helpful - unit tests are great when the api is used so often it would be painful to change it so you don't anyway. Otherwise I want to change the api and the code that uses it as requirements change. When I'm writing string or a list I'd unit test that - but mostly that is in my standard library so I'm not. Instead I'm writing code th…

I'm sorry I don't really understand your argument; unit tests are bad because code changes? Surely if you're only testing small pieces then that works better when you make a change? You only need to update the tests for the part of code that changed, not everything that touches it. That's another great thing about mocks - your interfaces should be stable over time, so the mocks don't need to change that often, and when you're changing MyCalculator, all the dependencies to MyCalculator remain the same so you only have to update MyCalculatorTests.

This is what I mean about a well-factored code base; separate things are separate, and can be tested independently.

> Unit tests have proven more harmful than helpful

Why? I find them very useful. If I change a method and inadvertently break it somehow, I have a battery of tests testing that method, and some of them fail. Nothing else fails because I didn't change anything else, so I don't need to dive into working out why those other tests are failing. It's separation of concerns.

Re: Stepping down as Mockito maintainer after ten years

#215

Post by danparsonson »

bluGill wrote: post #207
danparsonson wrote: post #200

Earlier quoted context omitted.

That's not a counter-argument. Why don't you need to mock out the interfaces that you're not testing?

why would I? Either the code works either way or I'm glad to know I broke things when the seemingly unrelated tests breaks. Remember if a test fails the fault is almost always the last thing I changed. now I do take care to avoid writing tests that depend on other code's results that would be likely to change. This hasn't proven to be the problem I've so often been warned about though.

> Either the code works either way or I'm glad to know I broke things when the seemingly unrelated tests breaks

...or, you tested each thing individually, so only related tests break and you can quickly zero in on the problem. Isn't that easier?

Re: Stepping down as Mockito maintainer after ten years

#216

Post by mangodrunk »

danparsonson wrote: post #212
mangodrunk wrote: post #208

Earlier quoted context omitted.

I don’t want to take too much of a tangent, but in scientific studies, you are trying to understand some phenomena, and isolating variables can help with very complex things. A test is typically not that complex. Another example is the use of animals in testing medicine, it can help but it obviously would be much better to test directly on humans but we don’t for good reason. Your position is reasonable and I do thin…

> in scientific studies, you are trying to understand some phenomena, and isolating variables can help with very complex things. Not to labour the point here, but no, the primary reason you isolate variables in a scientific experiment is that you want to ensure you're only testing the thing you intend to test. A medical study is a good example - you want to be sure that the effect you observed was due to the drug you…

I appreciate your thoughtful comments but we do disagree.

>Is that right? In which case I would say: of course you need to update the tests.

That is right. I think it is bad for you to need to update a test where the input and output are the same. Your mock is there for you to essentially ignore, but now you need to update the test. You now do not know if you introduced a bug.

You are losing out on encapsulation, the test should not know about the internals, generally speaking.

>The dependencies of a function are also inputs of a kind.

Typically that should not be a concern to the caller of the function.

Re: Stepping down as Mockito maintainer after ten years

#217

Post by rurban »

cletus wrote: 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 dont use dummy services and I dont use mocking. I'm writing simulators to test things for HW or big services which are not available for testing.

Simulators need to be complete for their use cases or they cannot be used for testing.

Re: Stepping down as Mockito maintainer after ten years

#218

Post by fatso83 »

yearolinuxdsktp wrote: post #148
cletus wrote: 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…

Heavy mocks usage comes from dogmatically following the flawed “most tests should be unit tests” prescription of the “testing pyramid,” as well as a strict adherence to not testing more than one class at a time. This necessitates heavy mocking, which is fragile, terrible to refactor, leads to lots of low-value tests. Sadly, AI these days will generate tons of those unit tests in the hands of those who don’t know bett…

I get what you are saying, but you can have your cake and eat it too. Fast, comprehensive tests that cover most of your codebase. Test through the domain, employ Fakes at the boundaries.

https://asgaut.com/use-of-fakes-for-domain-driven-design-and...

Re: Stepping down as Mockito maintainer after ten years

#219

Post by krzyk »

vips7L wrote: post #192
krzyk wrote: post #187

Earlier quoted context omitted.

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…

> Handling JSON as a basics for language? Yes, even Mark Reinhold admitted that in the last "Ask the Architects" interview. >null restricted type will come with valhalla Will they? It's been 10+ years of Valhalla. Why is a compiler construct even behind project Valhalla? Kotlin has showed you don't need it to do them. > string templates had a try Yes they were over engineered and they failed to deliver a basic featur…

> Yes I agree, but it shouldn't take YEARS to ship anything. 11 years for a JSON api?! Come on.

Anything? Or maybe something that you specifically want?

It added records when I wanted them, it added streams and lambdas. I don't care for string templates (I thing those are ugly in any language).

null-restricted types would be nice but you have to understand that designing a language is not throwing every possible feature on top of it (like kotlin and resulting lack of readability it has and hard time updating to newer JDK), you have to design it, think of the possibilities, what users really want etc.

Valhalla type system results in addition of null-restricted types, as a natural evolution of the language.

Re: Stepping down as Mockito maintainer after ten years

#220

Post by throwaway7783 »

rcxdude wrote: post #197
throwaway7783 wrote: post #196

Earlier quoted context omitted.

But mocks are a model of the dependency. I don't quite see how a fake is a better model than a mock. In any case, I agree testing close to a real system, with actual dependencies where possible is better. But that's not done with a fake.

The kind of mocks the OP is arguing against are not really a model of the dependency, they're just a model of a particular execution sequence in the test, because the mock is just following a script. Nothing in it ensures that the sequence is even consistent with any given understanding of how the dependency works, and it will almost certainly need updating when the code under test is refactored.

My point is that a fake doesn't magically fix this issue. Both are narrow models of the underlying interface. I don't still quite understand why a mock is worse than a fake, when it comes to narrow models of the interface. If there is a method that needs to be called with a specific set up, there is no practical difference between a fake and a mock.

Again, none of this is a replacement for writing integration tests where possible. Mocks have a place in the testing realm and they are not an inherently bad tool.

Post reply on HN