[goatcode]

Test what you are testing. Are you testing a method or function? Mock its inputs. If your test of a function fails because an API or a database is not available, that's approaching an integration test. If there's a question of whether there are too many mocks being used, the dev may not have thought out a testing strategy well enough. Be certain of what you're testing.

That's what I usually go by.

[dragontamer]

Lets say that some codebase is using a custom bitonic sort (a highly-parallel, SIMD sorting algorithm) instead of a standard library sort.

So you have:

    array<Foo> myFunc(Baz b){
      someArray = bar(b);
      bitonicSort(someArray);
      return someArray[0:2]; // Return the top 3 elements after sorting
    }

So we're trying to test myFunc(). We have dependencies on bar() and bitonicSort(). There may be hidden dependencies on Baz class functions (maybe bar() calls Baz.func()).

Now we have a variety of mocking strategies. We could mock the Baz class. We could mock bitonicSort(), we could mock bar() function.

But does such mocking really make our testing life easier? I argue it doesn't. Our unit test really should just be written as the following:

    Baz initializeBaz(){
      // A consistent initialization across many
      // different tests
    }

    void unitTest(){
      Baz b = initializeBaz();

      array<Foo> a = myFunc(b);
      assert(a.size() == 3);
      assert(a[0] == Foo(1, 2, 3)); 
      assert(a[1] == Foo(4, 5, 6)); 
      assert(a[2] == Foo(7, 8, 9)); 
    }

Easy peasy. No mocking needed. Compare now if we mocked out the Baz class, or the bitonic-sort method. It just becomes an unwieldy mess.

There's no need to overthink things. Maybe have 2 or 3 different, reasonable, instantiations of Baz. If a bug is discovered in the future, create a Baz that represents that bug.

If bitonicSort isn't working correctly, its not our job (as writers of myFunc()) to care about bitonicSort's correctness. We are allowed to assume correctness upon our dependencies. It is also NOT our job to test bitonicSort. If we happen to catch a bitonicSort bug, that's good... but remember that bitonicSort will have unit tests of its own.

[goatcode]

Yes, I had a brain fart when I wrote my original comment. I think I should have meant to say mock dependencies (that we have created, not necessarily external ones, unless they're something like network calls), not inputs.

[dragontamer]

bitonicSort() is a hypothetical dependency. So at least, by my reading of the comment, it seems like you'd be recommending to mock out bitonicSort().

[goatcode]

Only if bitonicSort is something that you'd written and would test elsewhere, or it reaches out to resources outside of the immediate software in which its used.