7 ms·

95% agree with these opinions, but have a few disagreements, or perhaps the author had missed some great stuff. Two main ones: Mockito is, IMHO, much nicer tha

by mabbo 11y ago

95% agree with these opinions, but have a few disagreements, or perhaps the author had missed some great stuff. Two main ones: Mockito is, IMHO, much nicer than jMock. And Immutability is good, but 'final' is... complicated. I find it's often over used by people who don't know why they're using it.

meddlepal 11y ago
Can you expand on the later point about final please?
- mabbo 11y ago
  tl;dr: final parameters != immutable and safety, and they look like they ought to. A lot of people write "final" in front of every. single. declaration. And they do that because someone once told them that was good. But then you remember that Java is a language which all non-primitive types are passed by reference, so your 'final' is actually a final reference and not a const immutable object, like you might get in C. If someone passes in a final FooBar to a method, and you mutate the FooBar during the method for any reason, then after the method is done the object remains mutated. Just this week, that exact problem caused my team an entire day of headaches. Two methods were being called concurrently using Futures, passing the same object to each method. One method mutated the object slightly, the other relied on it having not been mutated. Hello race condition. I was so proud to have solved it, until I realized I'm the dolt who wrote the bug in the first place. Silly, I know. But the point is that final makes you feel safe when you might not be.
  - davnicwil 11y ago
    > If someone passes in a final FooBar to a method, and you mutate the FooBar during the method for any reason, then after the method is done the object remains mutated. Fair enough, but if FooBar is your class there's an easy fix for this - make FooBar immutable. If it's not, make an immutable wrapper object for it. Very true that relying on untrue assumptions about the immutability of your data will cause hard-to-spot bugs, but the solution is then just to guarantee everything is immutable, and define that as an assumption that cannot be false if everyone on the team follows the pattern. If somebody does break the pattern, then that, rather than the race condition down the line, is the real bug. The dev who wrote the mutable data class can just have that (re-)explained to them, so it doesn't happen again.
  - chii 11y ago
    i wish java had designed final to be semantically const just like C++ (but without the type level breakages that seems to happen in C++).
  - lmm 11y ago
    C const doesn't mean immutable either, and I suspect most Java programmers have no exposure to it in any case. Honestly I don't think final ever makes things worse. I struggle to imagine someone who would misunderstand in the way you describe having any success in Java - references are a pretty fundamental part of the language.
lmm 11y ago
jMock isn't great, but Mockito makes it too hard to understand which method you haven't stubbed; I find EasyMock with its explicit replay() step much easier.
- twic 11y ago
  I rather like Moxie for mocking: https://github.com/pobrelkey/moxiemocks https://github.com/pobrelkey/moxiemocks
- cam- 11y ago
  JMock at least blows up if you don't mock something. Powermock and Mockito will let it pass. It is a shame JMock's API is so wordy.
  - lmm 11y ago
    Like I said, Easymock. Powermock has an Easymock API too if you need the mocking statics/object creation.
  - mabbo 11y ago
    That's what I hate about JMock, lol. You had better mock everything, and better put them in the exact order they will occur in, or your test fails. Most JMock unit tests I see are essentially the exact same code as is being tested, written a second time in the unit test. So if I want to refactor or modify this code in any way, my unit tests break- even if functionally, my tests are doing exactly what their spec says. With Mockito, I can say 'Hey, if anyone calls this method with parameters sort of like this, give them this response', and then focus on my unit tests actually testing the output for a given input.
- mabbo 11y ago
  Eesh, let's agree to disagree. EasyMock has some advantages, but I find the readability of Mockito outweighs them.

by mabbo 11y ago

meddlepal 11y ago

Can you expand on the later point about final please?

mabbo 11y ago
tl;dr: final parameters != immutable and safety, and they look like they ought to. A lot of people write "final" in front of every. single. declaration. And they do that because someone once told them that was good. But then you remember that Java is a language which all non-primitive types are passed by reference, so your 'final' is actually a final reference and not a const immutable object, like you might get in C. If someone passes in a final FooBar to a method, and you mutate the FooBar during the method for any reason, then after the method is done the object remains mutated. Just this week, that exact problem caused my team an entire day of headaches. Two methods were being called concurrently using Futures, passing the same object to each method. One method mutated the object slightly, the other relied on it having not been mutated. Hello race condition. I was so proud to have solved it, until I realized I'm the dolt who wrote the bug in the first place. Silly, I know. But the point is that final makes you feel safe when you might not be.
- davnicwil 11y ago
  > If someone passes in a final FooBar to a method, and you mutate the FooBar during the method for any reason, then after the method is done the object remains mutated. Fair enough, but if FooBar is your class there's an easy fix for this - make FooBar immutable. If it's not, make an immutable wrapper object for it. Very true that relying on untrue assumptions about the immutability of your data will cause hard-to-spot bugs, but the solution is then just to guarantee everything is immutable, and define that as an assumption that cannot be false if everyone on the team follows the pattern. If somebody does break the pattern, then that, rather than the race condition down the line, is the real bug. The dev who wrote the mutable data class can just have that (re-)explained to them, so it doesn't happen again.
- chii 11y ago
  i wish java had designed final to be semantically const just like C++ (but without the type level breakages that seems to happen in C++).
- lmm 11y ago
  C const doesn't mean immutable either, and I suspect most Java programmers have no exposure to it in any case. Honestly I don't think final ever makes things worse. I struggle to imagine someone who would misunderstand in the way you describe having any success in Java - references are a pretty fundamental part of the language.

lmm 11y ago

jMock isn't great, but Mockito makes it too hard to understand which method you haven't stubbed; I find EasyMock with its explicit replay() step much easier.

twic 11y ago
I rather like Moxie for mocking: https://github.com/pobrelkey/moxiemocks https://github.com/pobrelkey/moxiemocks
cam- 11y ago
JMock at least blows up if you don't mock something. Powermock and Mockito will let it pass. It is a shame JMock's API is so wordy.
- lmm 11y ago
  Like I said, Easymock. Powermock has an Easymock API too if you need the mocking statics/object creation.
- mabbo 11y ago
  That's what I hate about JMock, lol. You had better mock everything, and better put them in the exact order they will occur in, or your test fails. Most JMock unit tests I see are essentially the exact same code as is being tested, written a second time in the unit test. So if I want to refactor or modify this code in any way, my unit tests break- even if functionally, my tests are doing exactly what their spec says. With Mockito, I can say 'Hey, if anyone calls this method with parameters sort of like this, give them this response', and then focus on my unit tests actually testing the output for a given input.
mabbo 11y ago
Eesh, let's agree to disagree. EasyMock has some advantages, but I find the readability of Mockito outweighs them.