Unit testing an alias method

Question

What would be the best practice for unit testing a method that only calls 2 other methods and no logic?

internal ICollection<ObjA> FunctionA()
{
    IEnumerable<ObjB> b = _factory.FunctionB();
    return FunctionC(b);
}

_factory.FunctionB() and FunctionC(b) both have unit tests for it, so if those methods broke we would know.

I'm considering faking both functions and just have a unit test that makes sure the methods are called from FunctionA(). But then if FunctionB() or FunctionC() changes, FunctionA() could become a false positive.

Answer 1

I would tend not to unit test private or internal methods as they should be executed when unit testing the public API.

Assuming this was a public method I would have tests that check that the return value you expect when calling FunctionA() based on the state of the private member _factory. Assuming you can control the output of _factory (via it being a mock-able interface, subclass-able base class, or just plain instantiated with a known value and passed into the constructor for the class) you can ensure that you get the expected output of FunctionA based on that initial input.

If you find that you are getting false positives every time either FunctionB or FunctionC are updated I would question why FunctionA exists at all. The more likely scenario is that unit tests that break on FunctionA will cause you to either change the internal implementation of FunctionA as the changes to FunctionB and FunctionC no longer make them a suitable implementation for FunctionA, or they will cause you to add unit tests for those functions to fix the indirect breakage in FunctionA.

In this specific example it appears that FunctionA is just a wrapper to convert ObjB's to ObjA's with a data source already specified by an internal factory class. For this specific scenario I would set up my tests for FunctionA so that if upper level requirements change (because new rules are implemented as to how to convert ObjB to ObjA) so that I could either put that new logic in FunctionA or FunctionC depending on which I think is more appropriate.

Example:

internal ICollection<ObjA> FunctionA()
{
    IEnumerable<ObjB> b = _factory.FunctionB();
    // in the future unit test may drive that a different implemetation is used 
    // based on some data about b.
    if(b.SomeCondition())
        return FunctionC(b);
    else
        return FunctionD(b);
}

Or it could be that C needs to change

internal ICollection<ObjA> FunctionC(IEnumerable<ObjB> objBEnumerable)
{
    ICollection<ObjA> objACollection = initializeCollection();
    foreach(var objB in objBEnumerable)
    {
        //updated logic to create objA from objB goes here
        objACollection.Add(createdObjA);
    }
    return objACollection;
}

Basically the answer to your question is "it depends", but I would err on the side of writing a potentially meaningless test if the coverage of functions B and C are already good in case A needs to divert in the first code example in the future.