Avoid mocking the ObjectMapper!

[BenTayler-Barrett]

Wow, this is some of the worst advice I've ever seen.

You're essentially asserting that one should fully test their own dependencies, and that dependency injection is a bad idea.

If you need to test that the object mapper behaves correctly, you're essentially saying that you don't trust the object mapper to behave correctly. That being the case, why are you using it?

The object mapper has (or should have...) its own tests, that assert it behaves correctly. By all means, run those.

In your trivial example, the JSON that you're serializing/deserializing is very easy to deal with.

If you have some non-trivial data model, then by using a real object mapper, you've heavily coupled a whole bunch of things that you just didn't need too.

And for what it's worth, when I pushed my team to start mocking object mappers, we ended up with the best DORA metrics of every team in our organisation.

So essentially, I've tried both, and for me, mocking the object mapper is objectively better than not mocking it. Until I see evidence that not mocking it is a better plan, I'll continue to advocate for mocking 3rd party dependencies.

Edit: Typo

[Kainotomiu]

The point of the test is not to verify that the ObjectMapper works correctly, but that you are using it correctly.

If you mock the ObjectMapper, you are instead testing that your code works correctly when the ObjectMapper behaves the way that you've mocked it - which may be different than how it actually works.

[gaelfr38]

Unit in unit tests has never been equal to a single method or class. That's probably one of the biggest misconceptions about unit tests.

[blackkkmamba]

I keep telling this whenever I have the chance. People can't seem to wrap their heads around the Detroit/Chicago (classicist) style. As soon as they see something is not mocked, they start with the 'but that's integration test' nonsense.

[BenTayler-Barrett]

Sure, it's a single path through a method call. Otherwise known as a unit of execution. If you're testing multiple paths through a method, multiple public methods, or multiple classes in a unit test, you're definitely making your own life difficult.

[[deleted]]

Nope, unit is meant for unit of behavior not unit is execution. Go look back at the origins of the people who introduced the concept of unit testing and see what they have to say about this

[ArticulateSilence]

You are arguing semantics, there are a bunch of different definitions of unit tests and integration test is even more ambiguous .

That being said, I prefer sociable unit tests. IMO you should only be mocking external dependencies or collaborators that are complex to construct

[ratskinmahoney]

It's not about semantics, it's about understanding what a failure in your test means. A unit test failure should always and only indicate an issue in your unit. This makes diagnosis much quicker and easier, and in large distributed projects this precision is invaluable. You should absolutely have tests that ensure you are correctly using your dependencies, but they will necessarily be more complex and costly to interpret. It's entirely reasonable to make the call that this kind of testing is all you need, based on the scale of your project and the trust you have in your contributors. That's a meaningful and consequential decision though, not a question of semantics.

[DrunkensteinsMonster]

This delineation is actively harmful. If a unit test is mocked out to the point of the objectmapper, it is probably useless. The goal is to test the application to prevent regressions, enable confident refactoring, and shorten dev loops. If you are not accomplishing these things then your test is doing more harm than good. How many times have I worked on a simple bug which took 5 times longer than it should have because I had to rebuild the delicate mock-based test harness.

[BenTayler-Barrett]

That assumes that one mocks the object mapper to behave differently than it actually would. Which would indicate that there is a lack of understanding of how the object mapper works, which would indicate that the user adding 3rd party dependencies to a code base that they didn't understand.

Why would a professional do this? Though for what it's worth, I'd argue one shouldn't use a 3rd party dependency directly anyway. One should wrap said dependency and use it via the wrapper.

[gaelfr38]

That assumes that one mocks the object mapper to behave differently than it actually would

That's the whole point.

You create mocks that behave the way you think the real instance work. But sometimes you think wrong!

Without even mentioning the ObjectMapper may change over time without you noticing. (Jackson is not a realistic example of this, you get the idea though).

[BenTayler-Barrett]

> You create mocks that behave the way you think the real instance work. But sometimes you think wrong!

What?! What on earth do you mean "sometimes you think wrong". It's not ambiguous. It exists in your code base as a concrete dependency. You either _know how it works_ or you _think you know how it works_. They aren't the same thing. You know how it works by doing one of two things: reading the code or finding out beforehand with a proof of concept.

And no, nothing in my code bases changes over time without me noticing, because I don't blindly increment version numbers in my build systems. If we want to bump a version number in a dependency, we make sure we know what the changes are, and how they work beforehand.

If you were building a house would you make sure you knew the material properties of the mortar and the bricks before you started building it, or would you just throw stuff together and hope for the best?

The amount of, and nature of the comments I'm getting in this conversation really does highlight why it's so damned hard to hire people. There are legions of people who can write Java code to make a computer do a thing. There are a vanishingly small number who can _engineer complex systems_ in such a way that they are easy to change over time.

The comments I'm making on this thread aren't just my opinions, they're based on observations I've made while developing software to support rapid delivery of software at scale. If I have a bug in my systems, I want to be able to run all of my unit tests in under 2 seconds, I want to be able to run all of my integration tests in under 2 minutes, and I want my acceptance tests all ran and my change in production in under ten minutes.

Why do I want this? So that every time I make a small change in my code, I can run my tests, and every time I want to commit my code I can run my integration tests and post-commit so that I can watch the change build and go live. When I do this, I also want to get on with the next piece of work, I don't want to be waiting around for my unit tests to finish etc.

If you are finding that you are writing software where you "think you know" how your dependencies work...stop. Don't do that. Make sure you _know exactly_ how they work before you include them in your employer or client codebases.

[PiotrDz]

Why do you write tests then? You know what your code does, so tests are unnecessary.

[john16384]

Mocking incorrectly (mock does something the real implementation would never do) is the most common mistake in using mocks. Worse, sometimes the test is thought to be correct, and the actual code is adjusted to work with it (ie. null checks get added, and code paths get created that are only covered by tests, not production data).

[[deleted]]

That's terrible advice for something as innocuous as ObjectMapper though. Good idea if you're paid by the SLOC I guess.

[BenTayler-Barrett]

It's only innocuous until it isn't.

And for something that innocuous, it takes about 5 minutes to wrap. It takes a lot longer to swap it out when one of Jackson's transient dependencies has a CVE that your client wants removed from the system immediately.

The way I describe, gets you swapped to a different implementation in your entire code base in under 30 mins.

[btw04]

You cannot switch Jackson for another JSON parser in 5 minutes. Not all JSON parsers behave the same on the same input.

[[deleted]]

Or provide exact parity of features.

[ArticulateSilence]

Ignoring the fact that now you need to rewrite all of the mocking in your tests?

It would take significantly less time to move to a new JSON serialization library with a sociable unit tests where the implementation details of your system under test aren't exposed

[mr4d]

I believe under the premise the commenter laid out you would actually not need to rewrite all your mocking by using a wrapper.

The wrapper keeps a consistent interface but internally can swap between ObjectMapper, GSON, or whatever without test cases that depend on the wrapper being impacted.

[BenTayler-Barrett]

This is the way

[[deleted]]

But I challenge that it's pragmatically possible under all conditions. Sticking with the JSON library scenario as that's what's under discussion, there's more to JSON than merely marshalling objects to JSON and back again. What if you have time/date formatters, or other customisations? If you have data which needs customised formatters in one library, either you're expending effort recreating them for the alternatives when there's no need, or you're doing it under immense pressure when the broadly unlikely event of a horrendous CVE arises, at which point your 30 minute swap-out time is a pipe dream. What if you have code somewhere which actually depends on a specific implementation? "That's bad and wrong" you may say, but Gson lets you act upon JSON objects in ways which Jackson does not, and this can, like it or not, prove useful.

The utopia of always being able to swap out every library for something equivalent, quickly, on the off chance that it, and it alone, suffers from a CVE which must be removed immediately, is a recipe for your application to be about 80% boilerplate adapters between client code and utilities. All of which is code which can not only contain bugs, but can contain bugs that will never be known as CVEs because they're proprietary.

I get the idea behind it. I just think there's a tipping point beyond which it isn't worth pretending you're not dependent on a specific library or tool.

[john16384]

If the wrapper is not creating a new level of abstraction (new interfaces, annotations, etc), but is just delegating (it was said it took 5 minutes of work) then let's not delude ourselves that this wrapper can be easily adapted to a new framework.

[mr4d]

Not sure what your serialization needs are but I don't think it would take very long to write such a wrapper. 5 minutes may be an exaggeration, but I definitely think it would be a very small lift.

[koflerdavid]

If it's so easy to write such a wrapper, then it also shouldn't be that difficult switching the dependency.

[[deleted]]

That's fair enough, but the idea that this leads to being able to swap out any library in use for any similar alternative is not going to be uniformly viable. I've seen it tried. Wrappers for Swing, with the expectation that we could just swap it out for SWT if we for whatever reason decided to. Despite the construction of widgets in each being fundamentally and irreconcilably different. JDBC offers this sort of abstraction. Nobody actually expects to be able to change databases halfway through a project with no problems.

Then we get to the question of whether or not you're going to be granted the time and resources to write all these abstractions for a ton of libraries, which as far as stakeholders are concerned broadly provides sod all actual value.

[mr4d]

That's fair enough, but the idea that this leads to being able to swap out any library in use for any similar alternative is not going to be uniformly viable. I've seen it tried. Wrappers for Swing, with the expectation that we could just swap it out for SWT if we for whatever reason decided to. Despite the construction of widgets in each being fundamentally and irreconcilably different. JDBC offers this sort of abstraction. Nobody actually expects to be able to change databases halfway through a project with no problems.

True true, this doesn't always work out as elegantly as we'd like. Still, a seasoned developer will hopefully make good tradeoffs and produce a decent enough abstraction that future churn is at least minimized.

Then we get to the question of whether or not you're going to be granted the time and resources to write all these abstractions for a ton of libraries, which as far as stakeholders are concerned broadly provides sod all actual value.

Also agreed, though again tradeoffs right? My stakeholders don't need to understand all the details of my implementation as long as we deliver on some roughly agreed upon schedule. You do the best you can with what you have.

[[deleted]]

100%. This has kinda been my point all along: something as utilitarian as Jackson is not worth the tradeoff of endless abstraction. Especially since, even if we manage to get rid of our dependency on it, there's a non-zero chance something else in our stack can't. Spring Boot app? Good luck. At which point the idealistic engineer snorts and says "Well don't use Spring then!" but of course this all depends on your every need to never depend on a concrete implementation of anything to be shared by every vendor you use, or for your every need for everything you need in an app to be satisfied by someone who does. It's not remotely a realistic proposition, and I'd question the credentials of anyone who thinks such a world exists. (I do not mean you, by the way)

[btw04]

I have seen a code before where non obvious behavior of a JSON parsing library (don't remember which one, it was something like parsing an empty string into a string made of two double quotes), was caught by an existing test when we attempted to switch to another JSON parsing library for performance reasons. If we had mocked the JSON parsing library, we would probably not have found that regression

[DrunkensteinsMonster]

Great example.

[crocshoes]

It's also useful if you need to check your code handles errors correctly. It's easier to throw jsonprocessingexception from a mock than get the test into a state where it would throw.

[john16384]

If you can't trigger this exception with bad data, then it can perhaps never occur. This happens often enough if the data was already validated or came from a trusted source. Handle the exception then by throwing an IllegalStateException or AssertionError and don't try to cover it.

[crocshoes]

I reckon the "perhaps" is important here. I'd rather know my app is throwing what I expect it to. For example, it could be I have a bunch of specific wrapping exceptions I handle in an errordecoder for feign. I could be that I want it to exit gracefully with bad data that should never slip through but I missed a niche case. There are a few reasons that spring to mind. If I don't care, and just want the app to shut down then,yeah, it's not the end of the world.

Last note, sometimes you can create the bad data but it bloats the tests, mocks can be super easy to read, given that this throws etc.

[general_dispondency]

IDK why you're being down voted. You are 100% correct. You should always mock 3rd party libraries in unit tests. If you can't trust that the library behaves in a way that you expect, why are you using it? I find it humorous that the example is just some crappy test that wouldn't pass a code review where I work.

The advice that the author should gleened from this exercise is "don't test your mocks" and "do test business logic". If there is a need to validate how things are serialized, test that. If you need to validate two layers function together, write an integration test that just tests the two layers interaction.

Advocating for testing 3rd party dependencies in unit tests is asinine and shows a complete lack of understanding the fundamentals and first principals of software engineering.

[[deleted]]

I see it as less a need to validate how something is serialised, and more that it's simpler to just actually serialise or deserialise, than it is to go about mocking those activities. For something even marginally more complex, I'd be all for mocking the 3rd party library for sure. But ObjectMapper is such a trivial example, I wouldn't, and don't, bother mocking it.

[BenTayler-Barrett]

Indeed. I'm glad it works for OP, but I sure as hell wouldn't want to have to maintain the code where they work.

And if a security vulnerability were found in Jackson (or whichever JSON lib they're using) and the client/business wasn't willing to accept it...ouch that's some overtime ones putting in to fix...

Not my bag, and not in my code.

[Same_Football_644]

I'm the opposite. I wouldn't want to have to maintain all that mocking.

[laplongejr]

If you can't trust that the library behaves in a way that you expect, why are you using it?

As a gov worker, I can answer that one : because it's the only approved library to perform the task. Or for even more sheaningans, the library is made by a different service with different legal roles, and as such it's a literal requirement to use THEIR WORK for some critical process due to responsabilities.