Best way to unit test methods that call other methods inside same class

Question

I was recently discussing with some friends which of the following 2 methods is best to stub return results or calls to methods inside same class from methods inside same class.

This is a very simplified example. In reality the functions are much more complex.

Example:

public class MyClass
{
     public bool FunctionA()
     {
         return FunctionB() % 2 == 0;
     }

     protected int FunctionB()
     {
         return new Random().Next();
     }
}

So to test this we have 2 methods.

Method 1: Use Functions and Actions to replace functionality of the methods. Example:

public class MyClass
{
     public Func<int> FunctionB { get; set; }

     public MyClass()
     {
         FunctionB = FunctionBImpl;
     }

     public bool FunctionA()
     {
         return FunctionB() % 2 == 0;
     }

     protected int FunctionBImpl()
     {
         return new Random().Next();
     }
}

[TestClass]
public class MyClassTests
{
    private MyClass _subject;

    [TestInitialize]
    public void Initialize()
    {
        _subject = new MyClass();
    }

    [TestMethod]
    public void FunctionA_WhenNumberIsOdd_ReturnsTrue()
    {
        _subject.FunctionB = () => 1;

        var result = _subject.FunctionA();

        Assert.IsFalse(result);
    }
}

Method 2: Make members virtual, derive class and in derived class use Functions and Actions to replace functionality Example:

public class MyClass
{     
     public bool FunctionA()
     {
         return FunctionB() % 2 == 0;
     }

     protected virtual int FunctionB()
     {
         return new Random().Next();
     }
}

public class TestableMyClass
{
     public Func<int> FunctionBFunc { get; set; }

     public MyClass()
     {
         FunctionBFunc = base.FunctionB;
     }

     protected override int FunctionB()
     {
         return FunctionBFunc();
     }
}

[TestClass]
public class MyClassTests
{
    private TestableMyClass _subject;

    [TestInitialize]
    public void Initialize()
    {
        _subject = new TestableMyClass();
    }

    [TestMethod]
    public void FunctionA_WhenNumberIsOdd_ReturnsTrue()
    {
        _subject.FunctionBFunc = () => 1;

        var result = _subject.FunctionA();

        Assert.IsFalse(result);
    }
}

I want to know wich is better and also WHY ?

Update: NOTE: FunctionB can also be public

Answer 1

Edited following original poster update.

Disclaimer : not a C# programmer (mostly Java or Ruby). My answer would be : I would not test it at all, and I do not think you should.

The longer version is : private/protected methods are not parts of the API, they are basically implementation choices, that you can decide to review, update or throw away completely without any impact on the outside.

I suppose you have a test on FunctionA(), which is the part of the class that is visible from the external world. It should be the only one that has a contract to implement (and that could be tested). Your private/protected method has no contract to fulfil and/or test.

See a related discussion there : https://stackoverflow.com/questions/105007/should-i-test-private-methods-or-only-public-ones

Following the comment, if FunctionB is public, I'll simply test both using unit test. You may think that the test of FunctionA is not totally "unit" (as it call FunctionB), but I would not be too worried by that : if FunctionB test works but not FunctionA test, it means clearly that the problem is not in the subdomain of FunctionB, which is good enough for me as a discriminator.

If you really want to be able to totally separate the two tests, I would use some kind of mocking technique to mock FunctionB when testing FunctionA (typically, return a fixed known correct value). I lack the C# ecosystem knowledge to advice a specific mocking library, but you may look at this question.

Answer 2

I subscribe to the theory that if a function is important to test, or is important to replace, it is important enough to not be a private implementation detail of the class under test, but to be a public implementation detail of a different class.

So if I am in a scenario where I have

class A 
{
     public B C()
     {
         D();
     }

     private E D();
     {
         // i actually want to control what this produces when I test C()
         // or this is important enough to test on its own
         // and, typically, both of the above
     }
}

Then I am going to refactor.

class A 
{
     ICollaborator collaborator;

     public A(ICollaborator collaborator)
     {
         this.collaborator = collaborator;
     }

     public B C()
     {
         collaborator.D();
     }
}

Now I have a scenario where D() is independently testable, and fully replaceable.

As a means of organization, my collaborator might not live at the same namespace level. For example, if A is in FooCorp.BLL, then my collaborator might be another layer deep, as in FooCorp.BLL.Collaborators (or whatever name is appropriate). My collaborator might further only be visible inside the assembly via the internal access modifier, which I would then also expose to my unit testing project(s) via the InternalsVisibleTo assembly attribute. The takeaway is that you can still keep your API clean, as far as callers are concerned, while producing verifiable code.

Answer 3

Adding on to what Martin points out,

If your method is private/protected - do not test it. It is internal to the class and should not be accessed outside the class.

In both the approaches that you mention, I have these concerns -

Method 1 - This actually changes the class under test's behaviour in the test.

Method 2 - This actually does not test the production code, instead tests another implementation.

In the problem stated, I see that the only logic of A is to see if the output of FunctionB is even. Although illustrative, FunctionB gives Random value, which is tough to test.

I expect a realistic scenario where we can setup MyClass such that we know what FunctionB would return. Then our expected result is known, we can call FunctionA and assert on the actual result.

Answer 4

I personally use Method1 i.e. making all methods into Actions or Funcs as this has hugely improved code testability for me. As with any solution there are pros and cons with this approach:

Pros

1. Allows for simple code structure where using Code Patterns just for Unit Testing might add additional complexity.
2. Allows classes to be sealed and for the elimination of virtual methods that are required by popular mocking frameworks like Moq. Sealing classes and eliminating virtual methods makes them candidates for inlining and other compiler optimizations. (https://msdn.microsoft.com/en-us/library/ff647802.aspx)
3. Simplifies testability as replacing the Func/Action implementation in a Unit test is as simple as just assigning a new value to the Func/Action
4. Also allows for testing if a static Func was called from another method since static methods can not be mocked.
5. Easy to refactor existing methods to Funcs/Actions since the syntax for calling a method on the call site remains the same. (For times when you can't refactor a method into a Func/Action see cons)

Cons

1. Funcs/Actions can't be used if your class can be derived as Funcs/Actions have no inheritance paths like Methods
2. Can't use default parameters. Creating a Func with default parameters entails creating a new delegate which might make the code confusing depending on the use case
3. Can't use the named parameter syntax for calling methods like something(firstName: "S", lastName: "K")
4. The biggest Con is that you don't have access to the 'this' reference in Funcs and Actions, and so any dependencies on the class must be explicitly passed in as parameters. Its good as you know all dependencies but bad if you have many properties that your Func will depend on. Your mileage will vary based on your use case.

So to sum up, using Funcs and Actions for Unit test is great if you know that your classes are never going to be overridden.

Also, I usually don't create properties for Funcs but inline them directly as such

public class MyClass
{
     public Func<int> FunctionB = () => new Random().Next();

     public bool FunctionA()
     {
         return FunctionB() % 2 == 0;
     }
}

Hope this helps!

Answer 5

Using Mock its possible. Nuget : https://www.nuget.org/packages/moq/

And believe me its fairly simple and makes sense.

public class SomeClass
{
    public SomeClass(int a) { }

    public void A()
    {
        B();
    }

    public virtual void B()
    {

    }
}

[TestFixture]
public class Test
{
    [Test]
    public void Test_A_Calls_B()
    {
        var mockedObject = new Mock<SomeClass>(5); // You can also specify constructor arguments.
        //You can also setup what a function can return.
        var obj = mockedObject.Object;
        obj.A();

        Mock.Get(obj).Verify(x=>x.B(),Times.AtLeastOnce);//This test passes
    }
}

Mock needs method virtual to override.