Как выполнить модульное тестирование перегруженных функций?

Question

Итак, у меня есть класс, который выглядит примерно так:

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;
    }

}

Где DBParameter - это простой класс значений, который содержит такие свойства, как Server, DBName, DBType и т. Д.

Теперь я хочу добавить перегрузку в DoSomething, чтобы она принимала строку подключения вместо параметра DBParameter (предположим, что DatabaseDependency уже имеет перегрузку GetResults, которая принимает строку подключения).

Мой вопрос: у меня есть несколько модульных тестов, которые описывают различные логические пути, используемые для обработки результата из DatabaseDependency.GetResults. Когда я добавляю перегрузку к DoSomething, я бы по существу реорганизовал код, чтобы эта логика использовалась обеими перегрузками (то есть, вероятно, переместил бы его в закрытый метод). Как правильно провести модульное тестирование? Нужно ли иметь столько же модульных тестов для проверки всех логических путей для новой перегрузки, которую я добавляю?

Answer 1

Если ваш код остается таким, каким он сейчас выглядит, тогда да: вам нужно будет также выполнить модульное тестирование этого метода, по сути дублируя ваши усилия по тестированию.

Однако, если имеет смысл реализовать функциональность так, чтобы один метод просто вызывал другой, вы могли бы сделать этот другой метод виртуальным. Это позволит вам создать специфичный для теста подкласс, в котором вы просто убедитесь, что другой метод вызывает виртуальный метод с правильными значениями.

Как только это проверено одним или несколькими юнит-тестами, вам больше не нужно тестировать этот метод, потому что теперь у вас есть проверенное , что метод вызывает другой метод правильно, и вы можете сосредоточиться ваши усилия по тестированию по этому методу.

Answer 2

Если вы уверены, что ваш перегруженный метод, принимающий строку, просто преобразуется в объект подключения, а затем делегирует оригиналу, вам следует добавить еще один метод тестирования.

Однако это не работает, если вы реорганизуете базовые перегруженные методы, так что делегирование не происходит. В этом сценарии я чувствую себя более уверенно, повторяя все тесты для обоих методов.

Я думаю, что первый маршрут самый прагматичный. Однако рекомендуется время от времени запускать анализ покрытия кода, и это будет указывать позже, если потребуется больше тестов.

Answer 3

Да, рефакторинг общей обработки в частный метод - я предполагаю, что вы все равно это сделаете, независимо от соображений теста, дублирующий код плох. Интересно, что размышления о тестировании заставляют нас поступать правильно.

Затем у вас есть пара простых тестов для каждого перегруженного пути инициации.

Answer 4

Зависит от того, проводите ли вы тестирование «черного ящика» или «белого ящика», а также если ваше приложение использует обе версии метода.

Если вы предполагаете, что вы просто тестируете реализацию, тогда просто протестируйте «основную» версию. Если вы думаете в духе автора тестов, который знает только о представленном API (javadocs или аналогичном), вам нужно тестировать только на основе API, что подразумевает полное тестирование обоих методов.

Если ваше приложение использует только один метод, то следует отказаться от другого и создать условный тест версии, который завершится неудачно, если устаревший метод все еще существует в некоторой предварительно определенной версии. IE: принудительно удалить устаревший метод в какой-то момент.