[alecbz]

I've certainly seen people who mock almost everything to test units at the smallest scale possible because they think that's what they're supposed to.

E.g., I once saw someone test a factory method like:

  def make_thing(a, b, c):
    return thing(a, b, c)

with a unit test where they mocked `thing`, and ensured that calling `make_thing(a, b, c)` ended up calling `thing(a, b, c)`.

They write just a shit ton of tests like this for every single method and function, and end up writing ~0 tests that actually check for any meaningful correctness.

[AtlasBarfed]

harkens back to the early obsession with "100% code coverage" and java robots were coding tests on bean getters/accessors.

100% code coverage was a bad breadth-first metric when unit tests should be depth based on many variant inputs. Also, "100% code coverage" ignores the principle that80% of execution is in 20% of the code/loops, so that stuff should get more attention than worrying about every single line being unit tested.

Well, unless you were in some fantastical organization of unicorn programmers that had an infinite testing budget and schedule...

[oriolid]

A good exercise is to get 100% coverage for anything that uses ByteArrayInput/OutputStreams. The language enforces handling IOException for a bunch of methods that could throw one for a generic stream but never for a ByteArrayStream.

[shadowlight]

You should see the opposite of this. Where every module of code is unit testable with zero mocks and just a small subset of untestable IO functions packed in a neat corner.