4 ms·

It’s taken years off of my life dealing with the test mess people have made with it.

• nsxwolf 9mo ago
  Absolutely the worst. 1000 line test setups that shatter into pieces the instant you try to make the simplest change to a function. Makes refactoring an absolute nightmare.
  • pjc50 9mo ago
    What's specifically bad about Mockito here? Poor defaults for mocks?
    • eastbound 9mo ago
      I’ll answer: Nothing specific to Mockito, it happens in every language. Tests “solidify” code which makes refactoring hard. And yet, after refactoring, one can be happy to have tests to check whether there is any regression. Testing is hard. I’ve tried with AI today: No, it is still not capable of handling that kind of (straightforward) task (Using Claude).
      • blandflakes 9mo ago
        They also encourage/enable code that is less testable. If you use mockito to get your fake responses/assertions where you need them, you don't have to think about your class's dependencies to make your code testable and therefore better decomposed. I don't even do TDD, but I still find that thinking about how I'd test a class guides me toward better-factored code.
        • t-writescode 9mo ago
          One alternative to make code with typing styles in the Java way (as opposed to the Typescript or Go way) is to have a whole lot of custom interfaces and then you end up with a whole bunch of: doTheThing(foo: Fooable) { ... } when there's really only one Foo implementation in prod. It leads to (what feels like, to me) more code obfuscation in large projects, than the benefits that come out, at least for me. So Mockito and friends are a nice alternative to that. That is just my experience and opinion though, and there are definitely more valid or equally valid alternatives.
          • blandflakes 9mo ago
            I don't think we have to choose. Naturally finding the "right division of labor" is as infinite as finding the "right level of abstraction", but I think the ideal situation is to strive toward code that is easy to test without having to introduce a lot of mocks or without infinite layers of abstraction.
    • xienze 9mo ago
      IMO Mockito is fine, the problem I’ve encountered is people taking the easy way out and trying to test something that needs a real integration test with a convoluted series of mocks.
      • vips7L 9mo ago
        I've found that most of the time that if you need to mock, you probably just need to do an integration test.
        • asa400 9mo ago
          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 the early 2000s and achieved complete victory in the 2010s, like Agile and OOP, and now there are entire generations of devs who it’s not that they’re making a bad or a poorly argued choice, it’s that they literally don’t even know there are other ways of thinking about these problems because these ideas have sucked all the oxygen out of the room.
          • rgoulter 9mo ago
            > 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 good/effective way of doing it. But the idea of "you're just testing that the compiler works" comes to mind.
            • lisbbb 9mo ago
              Had my fill of both until I could not stand it anymore. So tired of the grifters--agile was sometimes good, but mostly a grift.
    • mrkeen 9mo ago
      You've just built a calculator, and now you want to test it. Well, you have to push buttons on a calculator, so you build a robotic hand. And that hand needs a power source and some intelligence. And you need to photograph and OCR the result from the calculator screen. This is kinda how we build software right? A little bit of "our logic" (calculation), represented as objects/actors/modules which "do things", but intermingled with million-LoC dependencies like databases and web servers. After a while it gets frustrating setting up the robot hand and OCR equipment for each test case. Maybe it's just easier to test manually, or skip testing entirely. At this point you can have an epiphany, and realise you only care about the numbers going in and out of the calculator, not the button pushes and pixels. Mockito swoops in and prevents you from having that epiphany, by making it easier to keep doing things the stupid way. Instead isolating the calculation from any IO, you can now write things like: when(finger.pushbutton(1)).then(calculator.setState(1)) when(calculator.setAnswer(3)).then(camera.setOcr(3)) (I've mostly worked in Java, but it seems like other languages typically don't let you intercept calls and responses this way)
    • CSDude 9mo ago
      It allows you to mock the whole universe so it becomes a hammer instead of nicely designed functions, interfaces.
    • Sankozi 9mo ago
      People using it wrong. It definitely should not be that popular. 95% of times when I see it I consider it a tech debt. You should be using it in rare cases when you want to verify very complex code that needs to be working with strict requirements (like calling order is specified, or some calls cannot be made during execution of the method). Usually it is used for pointless unit tests of simple intermediary layers to test if call is delegated correctly to deeper layer. Those tests usually have negative value (they test very little but make any modification much harder).
  • mangodrunk 9mo ago
    Which is absurd that people use mocks considering the tests are supposed to help with refactoring but because of the mocks they can’t make a change without breaking the test.
  • the_arun 9mo ago
    I wish there are tests written to cover functionalities (& race conditions) instead of covering lines/branches.