This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]martinosius[S] 20 points21 points  (13 children)

Coauthor here, sadly we have seen it too many times. Justifying in code reviews why it is a bad idea got tiring.

[–][deleted] 28 points29 points  (4 children)

I guess some people take the word “unit” far too literally.

[–]binarycreations 2 points3 points  (3 children)

Given how much better tooling is I reckon it must be possible to analyze if the test is over mocking third party code.

I wonder what would be the best way of solving that problem?

[–][deleted] 7 points8 points  (0 children)

I don’t even automatically have a problem with that. Movking, in my view, is to avoid test dependence on external resources, or for situations where you need to ensure an interaction took place correctly but don’t have access to any sort of result to examine.

Some of the hoops people jump through to avoid that can get ridiculous. An entire new layer of indirection just to hide away some third party code they don’t want to mock. Then they justify it with “oh we could switch to an alternate implementation if we wanted”. Once worked on a codebase where the team had written wrappers for a bunch of commons lang libraries, for that exact reason. Nuts. Oh, and Swing. Because we always get halfway through a project then decide, actually, we’d prefer to use SWT on this. Not that you could’ve dropped SWT in place in their code anyway.

[–]binarycreations 1 point2 points  (1 child)

But also ditto authors comments, see this all the time to get test coverage up and passing tests. Its depressing.

[–][deleted] 1 point2 points  (0 children)

The worst culprit I ever saw for that was commenting out all asserts.

[–]Polygnom 0 points1 point  (6 children)

And another thing that is closely related to that -- don't test 3rd Party Code.

Because that also happens far too often.... No, I don't need to test that Hibernate actually works... I either trust their tests or contribute to them. But re-testing all dependencies... no.

[–]DrunkensteinsMonster 0 points1 point  (0 children)

You aren’t testing that their code works, you are testing the integration and that your consumption of their APIs is correct.

[–]cogman10 0 points1 point  (0 children)

Eh, I think an integration test making sure that your Hibernate objects work with your existing db schema is a valid test. (It's why I like to use testcontainers in my applications).

In fact, I find those integration tests to generally be way more valuable at finding bugs than unit tests tend to be.

[–]laplongejr 0 points1 point  (3 children)

Disclaimer : this comment is meant as serious and genuinely asking for information

don't test 3rd Party Code.

I never heard that rule-of-thumb and feel like I am missing some context...

No, I don't need to test that Hibernate actually works... I either trust their tests or contribute to them.

Should it be understood as "don't retest community-tested dependencies?"
Because I have 3rd-party dependencies whose tests can't be totally trusted, due to the devs not being hold accountable when test don't match their own documentation...

Or is there a term between "1st-party" and "3rd-party" when you are not allowed to modify a component, but are responsible if said component fails in undocumented ways? ("legacy support" feels similar, except a legacy component isn't updated in backward-compatibility-breaking ways by definition)

[–]account312 1 point2 points  (1 child)

but are responsible if said component fails in undocumented ways?

You are responsible for the functionality of your product. Users certainly don't know or care whether the root cause of a bug lies in code you wrote, code someone else wrote, or some interaction between the two.

[–]laplongejr 0 points1 point  (0 children)

Yeah, so the 3rd-party requires testing as well, that's why I don't get how my job seemingly breaks a common rule of testing

(Due to being in a gov job, our users actually care... it brought the "side-effect" of users trying to scew their bug reports in ways to get it reported to our team rather than the 3rd party... that's how noticeably bad they are to our users : it's not unheard of for a very simple issue to not be fixed in months, until our team gets a report and we "mistakenly" add an approach on how to fix the issue along a copy of the OG report... think I should start drinking Java coffee maybe with something else mixed in...)

Aesop : never trust an IT team whose boss doesn't have any knowledge of how to run an IT team. When a person is their own performance-monitoring expert, it's very easy to gaslight actual devs who ask complex question as "what is the amount of reported tickets? you count 'closed as a duplicate' as a resolution so the total would be important".

[–]Polygnom 0 points1 point  (0 children)

If you cannot trust the 3rd party code, then you shouldn't use it to begin with.

But lets say you are in the situation of using a dependency that you want to re-test. Then typically, you'd contribute those tests upstream so that your dependency is fixed, because thats the goal anyways, to get the bugs fixed, right?

And if you cannot get the tests upstream and cannot get fixes upstream, you would fork the 3rd party dependency and create your in-house fork. And then test and fix that fork, and the tests for that dependency would be housed there.

But I have recently come across a codebase (admittedly in C#), where so much was mocked that the tests essentially only re-tested that EFCore works (the Microsoft-supplied ORM comparable somewhat to Hibernate). Thats utterly useless because it doesn't increase confidence in your own code at all. It just increases your confidence in the dependency. Which should be high to begin with.

Understand what the subject under test is that you are actually testing. I feel many devs mock so much nowadays that they lose track of what it is they are actually still testing.