* C should have a unit test proving its capabilities.
* B is allowed to have a unit test that depends on C (because C's unit tests prove its correctness).
* A is allowed to have a unit test that depends on B (similar to the B/C case).
---------
It seems like mocking was a way to "cut" the dependency between A and C. In particular, you usually get huge "dependency chains" between your code base. A depends on B, depending on C, depending on D... depnds on E, F, G, H, I... etc. etc. Pulling in all of this code for a unit test seems backwards. IMO, the solution isn't to use mocking, but to refactor your code to reduce the dependencies.
But if the code is outside of your control (ie: owned by another team, or even a 3rd party), maybe mocking is the best option.
"Flattening" your code dependencies, reducing the "height" of your layers will simplify your code logic and software engineering. But its not always an option in reality.
------
If you have a circular dependency: A depends on B and B depends on A, then:
1. Find a way to break the circular dependence. Invent a new class C: Maybe A depends on C, B depends on C, and C represents the shared interface between the two. Once broken up in this manner, A depends on C (and A unit tests depend on C), then B depends on C (and B unit tests depend on C), and finally you write unit tests for C itself. No mocking needed.
2. If #1 cannot happen, Both A and B must be unit tested together as a singular component. Trying to split it up using mocking is a fool's errand.
I pushed the hardware part into a class, injected it as a dependency to client code so I could materialize the BLE connection whenever I wanted.
The binary encoding/decoding wasn't tied to the class and was handled by a codec I wrote to decouple packet handling from the device. You only had to feed it a YAML file I wrote to model the device communication protocole. I read the manufacturer's specs and came up with a schema for rx/tx padding, etc.
When we changed devices, we just had to give another YAML file to the codec and the code worked.
All this to say that it was really hard to test before code refactoring and loosening the dependency on the actual device.
Once we had a nice interface, you could write a MockBLEDevice class even by inheriting from the real class, just changing the actual BLE connection to return something else and keeping everything else the same.
That's what I usually go by.
So you have:
array<Foo> myFunc(Baz b){
someArray = bar(b);
bitonicSort(someArray);
return someArray[0:2]; // Return the top 3 elements after sorting
}
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));
}
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.