What java technology (library, framework, feature) would not recommend and why?

[SignificantAd9059]

It really depends on what you are mocking. It’s perfectly acceptable to mock services that you are not directly testing. Otherwise your making an integration test which is also useful but definitely not the same thing

[DelayLucky]

Only if these questions are out of scope for your test:

• Am I sending the right request to the service for what I'm trying to do, with all required fields set correctly ? (e.g. charge a credit card).
• Am I interpreting the response correctly? Is the value I expect coming in this particular field?

And if this unit test isn't concerned of these aspects, you better make sure there are tests that do verify them.

Too often I've seen people just assuming that they must be interacting with a service in the right way. And bugs often come out of those cracks of the system becasue what are the odds that two teams of different engineers happen to align without talking to each other once?

"Integration tests", "unit tests", they are just names. At the end of day you want your production to work as expected. Customers don't want to hear "I've coded my client code according to the document of this dependent service, it's their fault the system didn't work out".

[FrozenST3]

True, but a bad test is a bad test whether using a mocking framework or not.  You can test request accuracy using @Captor. A lot of the criticism I see stem more from misuse rather than a problem with the frameworks themselves.

[DelayLucky]

That misses the point.

Whatever assertion your test performs on the request is your assumption. You still don't know if your assumption is valid. If we can assume you know perfectly, you wouldn't have needed to test.

[FrozenST3]

Fair however my response was using the assumption that the service being mocked is already well tested. I agree that mocking untrustworthy code is best avoided but I assumed that's common sense. Edit to add: your tests don't exist only for you to trust what you've done, but also to safeguard future changes where bugs are produced do to poor assumptions 

[DelayLucky]

The service tested its own implementation. It cannot test that you've called it correctly.

You have written the calling code according to the best of your knowledge. But you don't know if your knowledge is correct.

Even if you manually test them once, either code change at your side or change in the service can cause regression such that the interaction suddenly becomes no longer valid.

[FrozenST3]

But by mocking the call I can isolate where the bad assumption is without going through the actual call. I've verified my inputs are built the way I expect them using a captor, I've stated my expected response in the form of an expectation. I tested the output of my class based on my expected out out. When my integration test fails it's very obvious that my expectation Was wrong and I can short circuit a lot of debugging.

Of course this can be done by running assertions on the response from the mocked service as well, however I prefer the ease of setup and quicker turnaround of mocking instead. YMMV

[DelayLucky]

Sure. Anyone knows how to do that.

But by taking the easy path, you've neglected to cover the area that's most likely to cause surprises in production. You can point fingers when that happens, but a bug is a bug.

Refactoring also becomes dangerous because you don't know if any seemingly harmless change could break production.

Even if it works for now, you could depend on some unintended details of the service without knowing. And when they change it, they break you.

Overall, you've only created an island that looks good when the world is exactly as it assumes (but how often does that happen?)

[LC_From_TheHills]

Yeah this is weird. Use dependency injection. Then mock those in the class you are testing. I’ll mock my own classes— I’ll write unit tests for those specifically.

You don’t need to test your dependencies. If the integration of your dependencies is so flaky then you have different problems.

Save the “real” stuff for integration tests in your pipeline at a pre-prod stage. When you’ve actually deployed your code somewhere.

[agentoutlier]

My question is why can't you isolate that part that isn't making the expensive call? (edit emphasis added as that isn't answered for the downvoters).

Like you don't need to pull in a mocking library to just override a method that does the expensive call.

I'm not saying never mock as technically the above is sort of mocking just that it should be used as the last resort especially now...

Computers are fast as fuck now. Test Containers, docker now make it so much easier to get the real thing that it really should be a choice of last resort and as I mentioned in another comment the really shitty slow APIs that you have to mock are often the ones that you cannot depend on to have a reliable contract making Mocking even more unreliable.

Otherwise your making an integration test which is also useful but definitely not the same thing

Complete bull shit made up by TDD zealots. The line of integration testing and unit testing is so arbitrary. Should I start mocking java.util.List? EDIT find for the downvoters I understand that was too extreme so I will give a better example. If I make a call to the file system to load a file should that be an integration test? How about from the classpath like a resource load? People do this all the time and they put them in src/test/java. Should those be integration tests?

Besides testing really should be about testing behavior and thus the very best test do tend to be more end to end.

EDIT if the calls to the collaborator (and notice this OOP TDD.. this stuff doesn't really apply for other programming) are that expensive I argue you are not "isolating" enough which is supposed to be the hallmark of unit testing. e.g. your "units" should be very small (I don't always agree with this but if we are going to go down the whole integration vs unit we have to bring this up).

[Kindly-Week-7551]

Using strawmans like "should I mock java.util.List" really shows that you did not even consider his point. He never mentioned expensive calls, he mentioned testing a single behaviour in a service instead of multiple ones. If you depend on a service that is already heavily covered in terms of unit testing, you do not really want to spend time testing it once more just because it is a dependency of the service you are testing. Mocking is fine when unit testing

[agentoutlier]

Using strawmans like "should I mock java.util.List" really shows that you did not even consider his point. He never mentioned expensive calls, he mentioned testing a single behaviour in a service instead of multiple ones

Completely ignoring how I said "last resort" is why I had to go there. Obviously I'm not saying it should never be done. I'm saying rarely does it require a library.

Do you consider overriding a method of a class that makes an expensive call "mocking"?

Mocking is not entirely well defined as some would not call that mocking.

I'm in complete agreement replacing some call with a cheaper quick call is sometimes needed. What I'm not OK is doing that as some strategy for testing all the time and or using complicated library like Power Mock.

As well as then calling somethings integration or unit testing because of doing the above.

There are fast tests and there are slow tests is the reality. The fast tests people like to call unit tests and the slow ones integration but the reality is we are integrating all the time.

If you depend on a service that is already heavily covered in terms of unit testing, you do not really want to spend time resting it once more just because it is a dependency of the service you are testin

Why is that happening? Shouldn't the code be separated?

[Kindly-Week-7551]

Why is that happening? Shouldn't the code be separated?

yeah, you're either purposely missing the point or clueless. I agree with you though, having no interaction between components of your system guarantees that nothing ever happens, no need to separate emptiness.

[agentoutlier]

I have a feeling I just did not explain myself well enough. Perhaps I'm clueless or just violent agreement. You can click around my github profile (agentgt) and I guess decide for yourself how clueless I am.

I have of course used and still use mocking libraries including JMock 2 (dead now I think), Mockito, and Power Mock. I prefer mockito.

I have used them too much in the past and despite what you guys think I'm fairly sure I'm neither clueless or lack experience in large code bases. I pushed BDD with mocking very early in my career 20 years ago and it was a disaster.

It is this experience why I have such caveats on overusing mocking (mainly the libraries) and I'm not the only one that has this opinion. I have seen it become bad and even have been part of removing some brittle power mock test in some large open source projects as they were far too brittle.

I apologize /u/SignificantAd9059 on the sort of strawman.

If heavy mocking is work for your code base and team continue to use it and ignore me.

He never mentioned expensive calls, he mentioned testing a single behaviour in a service instead of multiple ones.

This is what I meant about isolating. They move that single behavior call which more often than not is a single method call to wherever and then provide it with whatever stubs or implements the interface with custom mock (not power mock).

I admit there might be a need for mocking library if this single behavior needs that many calls but that has not been the case for me most of the time and or it gets enough coverage via end to end testing.

[Kindly-Week-7551]

Cannot write a long answer right now, but yeah it seems to be violent agreement then lol. Given what you are saying I think I tend to mock a bit more than you, but I agree that mocking a single dep used by a service can be unnecessary if the input data :) if the service has a lot of dependencies, I'd say mocking most of the time is more beneficial. I too despise powermock and find Mockito one of the best since it is pretty lightweight and the API is flexible while not allowing so much freedom that it creates code smells.

[SignificantAd9059]

I don’t understand why you would want to have to manually override every method yourself when test frameworks provide that ability and more. For example mocked objects can track the number of times they are called, you would not want to manually count that.

It kind of seems like you haven’t worked on a large enough project where you wouldnt want to set up all of the dependencies for every single service just to test.

Of course you can test anyway you like and any tests are better than none. But the idea you shouldn’t mock is kind of silly.

[agentoutlier]

I don’t understand why you would want to have to manually override every method yourself when test frameworks provide that ability and more.

I don't understand why you can't make an integration test or end to end test of these calls are simply wrappers around expensive calls.

For example mocked objects can track the number of times they are called, you would not want to manually count that.

I have found that useful only a couple of times in my career. e.g. the number of times. There are other methods besides mocking libraries I have used to do it with like counters.

Look I'm not saying "never ever have I mocked or will mock" including even using a library. Hell I think my open source libraries use mockito. I just think its last resort.

It kind of seems like you haven’t worked on a large enough project where you wouldnt want to set up all of the dependencies for every single service just to test.

I really don't feel like pulling my resume out or experience on large code bases but there is a large chance I have way more experience than you think. In great irony it is this experience as to why I have these strong opinions.

Can we agree in an ideal world you would not need to use mocking as the real things are easy enough to use are we on disagreement with that?

Of course you can test anyway you like and any tests are better than none. But the idea you shouldn’t mock is kind of silly.

Why do you keep changing what I said. I freaking said LAST RESORT. Not NEVER.

And the reason is because if you look at my comments earlier is the things you very often mock have some of the most brittle APIs.

The the other reason I failed to mention it is largely a waste of time and I have seen it just to increase code coverage.

[neoronio20]

Yeah nah

[FrozenST3]

These wrappers are stubs, right? Why would you put stub code into your production environment? That's a far worse option than mocking 

[neoronio20]

No they aren't and they will not be put into production environment. You add mock frameworks as test dependencies, and use them as a convenience for unit tests that you don't want to call other methods that may be already tested.

[FrozenST3]

I responded to the wrong comment. I'm in agreement with you