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

201–210 of 220 posts

Re: Stepping down as Mockito maintainer after ten years

#201

Post by danparsonson »

asa400 wrote: post #109
danparsonson wrote: post #105

Earlier quoted context omitted.

> I almost lost my shit. Hopefully one day you'll back at that, and realise what an immature attitude that was.

I'm sorry you felt the need to post this in response to a figure of speech. Please keep your moralizing to yourself. Thank you.

Well of course it was a figure of speech - if you meant it literally then I would not by prodding you about your medical condition. I was posting in response to your story that a colleague proposed a way of working or technical solution to something, and that this in some way enraged or otherwise upset you. And then you thought that made a good story to share online. That is, as I said, an immature response to a disagreement.

Unless that whole paragraph was a figure of speech, in which case what I said doesn't apply, and we can both go about our days.

Re: Stepping down as Mockito maintainer after ten years

#202

Post by danparsonson »

wiseowise wrote: post #163
danparsonson wrote: post #105

Earlier quoted context omitted.

> I almost lost my shit. Hopefully one day you'll back at that, and realise what an immature attitude that was.

Hopefully one day I won’t have to deal with clowns like you.

Aw don't say that, you'll make me sad! There's nothing worse than a sad clown.

Re: Stepping down as Mockito maintainer after ten years

#203

Post by danparsonson »

bluGill wrote: post #126
danparsonson wrote: post #102

Earlier quoted context omitted.

Well, no - you don't. What you're describing is a very limited subset of testing, which presumably is fine for the projects you work on, but that experience does not generalise well. Integration testing is of course useful, but generally one would want to create unit tests for every part of the code, and by definition it's not a unit test if hits multiple parts of the code simultaneously. Apart from that, databases a…

Why would I want to create tests for every part of the code? I did that for years because I was taught that, but I came to realize it never mattered - if a test breaks it is because of the last thing I changed. I have a few flakey tests from time to time, but they have been not too bad to track down nd often taught me enough about how the system really worked as to be worth the time anyway.

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 worst. Is this what you're talking about? What I wanted to say is that unit tests should be written for every part of the code that you're testing, i.e. break it into bits rather than test the whole thing in one lump, or better, do both - unit tests and integration tests.

Re: Stepping down as Mockito maintainer after ten years

#204

Post by danparsonson »

wreath wrote: post #154
danparsonson wrote: post #102

Earlier quoted context omitted.

Well, no - you don't. What you're describing is a very limited subset of testing, which presumably is fine for the projects you work on, but that experience does not generalise well. Integration testing is of course useful, but generally one would want to create unit tests for every part of the code, and by definition it's not a unit test if hits multiple parts of the code simultaneously. Apart from that, databases a…

> Integration testing is of course useful, but generally one would want to create unit tests for every part of the code, and by definition it's not a unit test if hits multiple parts of the code simultaneously. The common pitfall with this style of testing is that you end up testing implementation details and couple your tests to your code and not the interfaces at the boundaries of your code. I prefer the boundary b…

Yeah I think that's a question of using the right tool for the job. Some projects are of a size that it's not really necessary to be more fine-grained, but as the number of moving parts increases, so too in my experience does the need to ensure those parts are individually working to spec, and not just the whole thing. A classic example might be something like a calculator that enshrines a complex piece of logic, and a piece of code that uses it. I would test both of those in isolation, and mock out the calculator in the second case so that I could generate a whole range of different return values and errors and prove that the calling code is also robust and behaves correctly. Separating them like this also potentially reduces the number of tests you need to write to ensure that you hit all possible combinations of inputs and outputs.

Re: Stepping down as Mockito maintainer after ten years

#205

Post by asa400 »

danparsonson wrote: post #201
asa400 wrote: post #109

Earlier quoted context omitted.

I'm sorry you felt the need to post this in response to a figure of speech. Please keep your moralizing to yourself. Thank you.

Well of course it was a figure of speech - if you meant it literally then I would not by prodding you about your medical condition. I was posting in response to your story that a colleague proposed a way of working or technical solution to something, and that this in some way enraged or otherwise upset you. And then you thought that made a good story to share online. That is, as I said, an immature response to a disa…

No thanks, I'll pass on the amateur psychoanalysis. Good luck to you sir.

Re: Stepping down as Mockito maintainer after ten years

#206

Post by bluGill »

danparsonson wrote: post #203
bluGill wrote: post #126

Earlier quoted context omitted.

Why would I want to create tests for every part of the code? I did that for years because I was taught that, but I came to realize it never mattered - if a test breaks it is because of the last thing I changed. I have a few flakey tests from time to time, but they have been not too bad to track down nd often taught me enough about how the system really worked as to be worth the time anyway.

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 that is only used a few places and those places both will change every few years as requirements change.

Re: Stepping down as Mockito maintainer after ten years

#207

Post by bluGill »

danparsonson wrote: post #200
wiseowise wrote: post #162

Earlier quoted context omitted.

> Using mocks properly is a sign of a well-factored codebase. Well-factored codebase doesn’t need mocks.

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.

Re: Stepping down as Mockito maintainer after ten years

#208

Post by mangodrunk »

danparsonson wrote: post #199
mangodrunk wrote: post #181

Earlier quoted context omitted.

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.

> 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 think isolation can be beneficial, but I still wouldn’t use mocking to do it.

>Smaller, more focused, cleaner tests are better in my opinion.

Cleaner is subjective. I can write “small” and “focused” functional tests that are also quick to run.

I am of the opinion that functional tests provide more value. They are testing more of the actual code than an approximation, which in turn gives a better indicator that it works. Functional tests are less likely to change unless the input/output changes.

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.

Re: Stepping down as Mockito maintainer after ten years

#209

Post by ben_w »

rgoulter wrote: post #106
asa400 wrote: post #97

Earlier quoted context omitted.

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…

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

Re: Stepping down as Mockito maintainer after ten years

#210

Post by bluGill »

danparsonson wrote: post #203
bluGill wrote: post #126

Earlier quoted context omitted.

Why would I want to create tests for every part of the code? I did that for years because I was taught that, but I came to realize it never mattered - if a test breaks it is because of the last thing I changed. I have a few flakey tests from time to time, but they have been not too bad to track down nd often taught me enough about how the system really worked as to be worth the time anyway.

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.

Post reply on HN