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

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: принудительно удалить устаревший метод в какой-то момент.