Unit testing the alias method
What would be the best practice to unit test 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 am considering spoofing both functions and just a unit test that makes sure the methods are called from FunctionA()
. But then, if FunctionB()
or FunctionC()
changes, it FunctionA()
can become false.
source to share
I would tend not to unit test private or internal methods as they should be executed when unit testing a public API.
Assuming it was a public method, I would have tests that verify what 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 (whether through it be a mock interface, a base class of a subclass, or simply created with a known value and passed to the constructor for the class), you can ensure that you get the expected result of FunctionA based on that initial input.
If you find yourself getting false positives every time FunctionB or FunctionC is updated, I wonder why FunctionA exists at all. A more likely scenario is that unit tests that break on FunctionA will force you to either change the internal implementation of FunctionA, since changes to FunctionB and FunctionC no longer make them a suitable implementation for FunctionA, or they will force you to add unit tests for those functions for fixes for indirect breakage in FunctionA.
This particular example shows that FunctionA is just a wrapper around the ObjB to ObjA conversion with the data source already specified by the inner factory class. For this particular scenario, I would set my tests for FunctionA so that when top level requirements change (because new rules are implemented how to convert ObjB to ObjA) so that I can either put this new logic in FunctionA or FunctionC, whichever is , I think it 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 may be that C needs to be changed
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 be wrong about writing a potentially meaningless test if the coverage of B and C is already good in case A needs to be diverted in the first code example in the future.
source to share