What is the correct way to unit test methods that mix dependencies and business logic?

Question

I'm struggling to come to a consensus on the right approach that can be used somewhat consistently to balance integration and unit testing.
Take the following method, that is extremely common to find in a C# .NET Core application.

public interface IBusinessLogicService 
{
    CalculationResult CalculateBusinessRuleResult(
        string businessRuleName, 
        int input
    );
}

public class BusinessLogicService: IBusinessLogicService
{
    private readonly ICache _cache;
    private readonly DbContext _context;
    private readonly BusinessValidator _validator;

    public BusinessLogicService(
            ICache cache, 
            DbContext context, 
            BusinessValidator validator //injected
    ) {
        _cache = cache;
        _context = context;
        _validator = validator;
    } 

    public CalculationResult CalculateBusinessRuleResult(
            string businessRuleName, 
            int input
    ) {
        var hasRule = _cache.TryGet(businessRuleName, out BusinessRule rule);
        if (!hasRule) 
        {
            rule = _context.BusinessRules.First(f => f.Name == businessRuleName);
            _cache.Add(businessRuleName, rule);
        }
        
        return ApplyRule(rule, intermediateValue);
    }

    internal CalculationResult ApplyRule(rule, input)
    {
        // Logic Line 1
        // Logic Line 2
        // Logic Line 3
        return new CalculationResult();
    }
}

In my mind, I identify CalculateBusinessRuleResult as an integration of parts (cache, database, and ApplyRule), and I view ApplyRule as a pure function. To me, this means that I should be unit testing ApplyRule and integration testing CalculatebusinessRuleResult.

My primary conflict is that I've seen it said many times that in this situation, ApplyRule is an implementation detail and should not be unit tested, as it is not directly exposed via the API Surface Area intended by the interface implementation. Furthermore there is an argument that if you have to mock dependencies, you are not unit testing, it is an integration test -- clearly visible by my dependency on the cache and database.

Is there really no unit-testable code here? To me, there is -- ApplyRule. A pure, functional business logic method.
This is the approach I've taken to a lot of code recently - declare dependency usage at the top of the public method, and then utilize those dependencies in units of business logic further down. Integration test this method, and then unit-test the bits of business logic below. This also lines up with the idea that an application should be produced of X number of end-to-end tests, +X number of integration tests, and ++X number of unit tests.

Answer 1

First, to your misunderstanding. You wrote

"If you have to mock dependencies, you are not unit testing, it is an integration test "

which is - in my understanding of those terms - incorrect. By injecting mocks, one does unit testing - the unit BusinessLogicService is tested in perfect isolation. Opposed to this, by not injecting mocks, but making use of "real" dependencies, this would become an integration test.

But now to your main question: the real issue I see with the code in this example (and which is IMHO the root cause why unit testing may be hard) is that it mixes up two different responsibilities:

• it integrates three different components (ICache, DbContext, BusinessValidator)

• but it also contains some logic which appears to be complex enough to make it worth writing unit test on its own: the rule evaluating logic in ApplyRule, which seems to be a "generic rule evaluator".

Now this little bit of technical debt may be acceptable in this specific case, but if that really bothers you, and you think unit testing by mocks is overcomplicating things, you can resolve this by extracting the code in ApplyRule into a new class (which is then injected into BusinessLogicService as well). By separating the responsibilities this way, ApplyRule is not an "implementation detail any more" and you can (and should) write unit tests for it.

Let me add that in the real code (outside of this contrived example), it may be not be necessary to create a new class for ApplyRule at all. It may be perfectly possible that there is already a class where it fits well. Maybe one can move it into the BusinessRule class instead, or the class of intermediateValue, which we currently don't know. But to make such a decision, one needs to see the real thing, know the real names and responsibilites of the sourrounding classes.

Answer 2

Unit Testing

Is about testing a unit of code.

Pure functions are pretty trivial, you test the function.

But what is CalculateBusinessRuleResult? Its not a unit, the object its embedded in is the unit.

Which still means you should unit test it. Pass appropriate stubs/mocks into the constructor. Then call CalculateBusinessRuleResult and if that had collaborators (pass in mocks/stubs for those too).

Integration Tests

These are for just those pieces of code that you cannot pass a mock/stub into. They must have an external collaborator/service/database/filesystem.

They should only be applied to the smallest sliver of code on your end, and as close to where the system 'integrates' with the collaborator.

End 2 End tests

These are the test where the whole system is strung together with as few mocks/stubs as possible. These shouldn't test work, but the stringing together of components.