How to design and test methods with complex orchestrating logic? - unit-testing

Question

I'll start my question with short example:
SomeResult DoSomething(input)
{
var a = svc1.getA(input);
if (condition with a)
{
var b = svc2.getB(a);
if (cond with b)
{
var c = svc3.getC(b);
if (cond with c)
{
}
else
{
}
}
else
{
}
}
else
{
}
}
I believe the idea is clear here. We have complex branching logic where conditions depend on interim results returned by injected services.
When we want the part of cond with c we have to mock svc1 and svc2 and svc3.
To apppear at cond with b we have to mock svc1 and svc2.
Thus we replay all upper parts of execution path every time we go level deeper. Guess how it is usually done? Bingo, copy-paste!
We have bunches of unit tests where most of the lines are occupied by objects' (a,b,c...) initialization and services mocking. When a, b or c are objects with tens of properties all this looks like a real hell. Tiny change in cond with a can easily break 20 tests simultaneously.
I insist on having some notion of "jump strait to the place I want to test".
What if we changed the code like that:
SomeResult DoSomething(input)
{
var a = svc1.getA(input);
if (condition with a)
{
var b = svc2.getB(a);
if (cond with b)
{
ProcessBLikeThis(b);
}
else
{
}
}
else
{
}
}
Then we could test ProcessBLikeThis separately from unrelated logic.
Yet for it to be testable it must be public. Moreover, as we want to have tests verifying that ProcessBLikeThis was called with the given argument depending on cond with b we either need to use isolator or make ProcessBLikeThis to be a method of some interface.
However, there is no other necessity for such granular design besides DRY-adherent testability.
So I'd appreciate some guidance here how to design and test such methods.
Addition:
I also forget to mention that my teammates are strongly against putting initialization logic in reusable methods as they see no strict border line between what can be put there and what can not and expect that some day someone will extend the code and break tests logic. They prefer copy paste as a mean of isolation.

Answer 1

my teammates are strongly against putting initialization logic in reusable methods as they see no strict borderline between what can be put there and what can not and expect that some day someone will extend the code and break test logic. They prefer copy / paste as a mean of isolation.
If your team wants to repeat themselves and you don't want them to, then that discussion needs to take place and a consensus formed so that everybody works with the same goals in mind. There are arguments for repeating some test setup code, usually down to readability, however, this can usually be overcome by naming any methods and variables sensibly so that their usage is obvious.
The argument that tests can't reuse code because somebody might change the shared code and break tests is a bit of a null argument. If somebody did change the shared logic and a bunch of tests didn't break you would have a larger problem. As you've said, the more likely scenario is that a small change in the production code will result in a bunch of tests failing. If the tests don't share relevant setup code, then the fix is likely to be blindly copy/pasted into each of the tests to make them work.
That said, the usual way to simplify testing is to create a different level of indirection so you're testing less. With the code you've posted, one approach might be to separate the flow logic from the action logic.
You might end up with code something like this (the names would obviously need to be tailored to your situation):
interface ISomeActioner {
bool IsTriggered( SomeStateProvider state);
SomeResult TriggeredAction(SomeStateProvider state);
SomeResult UntriggeredAction(SomeStateProvider state);
}
SomeResult DoSomething(input) {
SomeResult result = Unknown;
foreach(var actioner in _someActions) {
if(IsTriggered(/* some state provider */)) {
result = actioner.TriggeredAction(/* some state provider */);
} else {
result = actioner.UntriggeredAction(/* some state provider */);
}
if(result != Unknown) break;
}
return result;
}
You then end up implementing several classes that implement the ISomeActioner interface. Each one of these classes is straightforward; it checks the state from the state provider and returns a flag to indicate which of its other functions should be called. These classes can be tested in isolation to make sure that each public method does what is expected, by setting up the SomeStateProvider to the appropriate state before calling each of its methods.
An ordered list of these classes would then need to be injected into the class containing the DoSomething method. This allows you to use mocked instances of the interface when testing the DomeSomething method, which effectively becomes testing of a for loop.