Question

So I have a class that looks something like the following:

public class MyClass
{

    DatabaseDependency _depend;

    public MyClass(DatabaseDependency depend)
    {
        _depend = depend;
    }

    public string DoSomething(DBParameter database)
    {
        var result = _depend.GetResults(database, ...);
        string response = String.Empty;        

        // some logic to process the result 

        return response;
    }

}

Where DBParameter is a simple value class which contains properties like Server, DBName, DBType, etc.

Now, I want to add an overload to DoSomething so that it accepts a connection string instead of the DBParameter parameter (assume that DatabaseDependency already has a GetResults overload which accepts a connection string).

My question: I have several unit tests which describe the various logical paths used to process result from DatabaseDependency.GetResults. When I add the overload to DoSomething, I would essentially refactor the code so that this logic is reused by both overloads (i.e. probably move it to a private method). What is the right way to go about unit testing this? Do I need to have just as many unit tests to verify all logical paths for the new overload I am adding?

Answer 1

If you’re confident that your overloaded method taking a string just converts to a connection object and then delegates to the original, you should add one more test method.

However this breaks down if you refactor the underlying overloaded methods such that no delegation takes place. In this scenario I’d feel more confident replicating all the tests for both methods.

I think the first route is the most pragmatic. However it’s a good idea to run code coverage analysis once in a while, and that will indicate at a later time if more tests are required.