4

I am in jvm hell. I have been given a task to add mockito tests. All the existing documentation concerning junit 4 is out of date. Need to use junit 5. All mockito tutorials are out of date. I thought mockito was stupid before junit 5. Now it is “really” stupid. The tutorials I am reading are shit. We have wandered into bleeding edge fucktardness. Kill me now.

Comments
  • 1
    Dunno what you mean.

    JUnit 5 with the extension model is pretty awesome.
  • 1
    @IntrusionCM I have a controller class that has several dependencies.

    Trying to add tests for it.

    One of the classes I wish to mock is created on the fly with new keyword in the method under test. This class goes off to an external system. Is it possible to test this using mockito and junit 5? Every time I read the mockito documentation my head explodes. I do not wish to refactor the existing code at this time.
  • 3
    @Grumpycat

    A. the whole point of adding tests is to characterise the current behaviour, build yourself a safety net, **so you can change these controllers / services via refactors**. I recommend reading up on why you add tests to things as this understanding is critical to doing a good job
    B. Breaking dependencies to add tests is the point. TDD "prevents" tight coupling outright but since you're adding them after the fact, you're going to have to do that decoupling now if you want to move fast enough.
    Decoupling your code is almost never a bad thing so bite the bullet and extract what you can out to a new service or something. Just enough of a refactor to break the hard dependency (use an interface or something instead)
    C. Why are you testing controllers? Endpoints and services are where the meat of a system's functionality is / should be
  • 0
    ^ tired so blunt
  • 0
    @Grumpycat Your code needs refactoring before you can sensibly test it. Simple as that.

    This is why tests are added at the time of writing rather than afterwards - code needs to be *designed* so it can be sensibly unit tested - and sounds like yours isn't.

    I'd push back up and say this isn't viable work until refactoring has been done.
  • 0
    @AlmondSauce I don't think the work needs delaying, it just needs to be communicated to the team that it's a tricky characterisation and will take a bit longer than expected
  • 0
    @Grumpycat @MammaNeedHummus Thanks. The requirement is 80 percent coverage. I picked the controller because it had 1 unit test.
  • 0
    The whole problem with mockito is that it relies on reflection. Reflection makes it difficult to reason about what you are doing and why. Then there is the onslaught of the many different annotations that you have to read up on and try to understand what each one is doing. Without a coach, you are reduced to randomly testing and trying to understand what the fuck is going on. It turns into a blender of dysfunction. Welp.
  • 0
    @Grumpycat

    I feel a bit of empathy.

    Testing isn't easy, but annotations are well documented in my opinion.

    Compared to JUnit 4… JUnit 5 has a lot more to offer.

    Mockito isn't really my forte.

    But if you want to test a route, that sounds like an integration test.

    I'd deny any incoming PR that tries to mock a framework controller to do an half assed integration test.

    WebTestClient in Spring (fuck Spring) or MicronautTest (yay) are the right tool for that... Not Mockito directly.

    The framework then takes care of the heavy lifting and provides the proper set up mocks.

    Anything else: Nope.
  • 0
    Piling garbage on top of garbage.

    Thats my job.
  • 0
    I tried refactoring out the class and the new by extracting an interface and creating a static factory method like Josua Bloch recommends but my boss wants unit tests without the refactoring. Fuck it. Time for a martini.
  • 0
    Every time a java developer uses reflection a maintainer dies.

    That is all.
  • 0
    Fucking @Autowired is the devil. Any advice on figuring out why @Autowired isn’t working?
  • 0
    My boss is convinced that you can add unit tests without refactoring. Hah! Like to see him try. 8 more hours of hell before I am on vacation….
  • 0
    Mocking statics no longer works.

    What a disaster. Look into it next year.
  • 1
    Making slow progress. Adding tests to existing code that you are not allowed to change and did not write requires exceptional patience and creativity. Hell is other people’s code.
  • 0
    I got this up to 57 percent coverage and explained that I would need to refactor to get any higher.

    I only need to refactor like two or three classes where a JavaScript developer was learning java. I am not touching them without management directives.

    Cause then you get into the you broke it you fix it fiasco.
Add Comment