Статический класс / метод / свойство в модульном тесте, остановить его или нет

Update

следует ли использовать статический класс / метод / свойство в среде разработки модульных тестов, учитывая, что невозможно протестировать его, не представив оболочку, которая снова не тестируется?

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

Ответы на вопрос(4)

Технически тыcan высмеивать статический метод в Java сPowerMock, но если вам нужно сделать это, я бы настоятельно рекомендовал рефакторинг вашего кода. Я думаю, что статические методы всегда должны бытьprivate и используется только внутри классов, в которых они определены, для внутренних целей. Я считаю публично выставленный статический метод какзапах кода.

Статические методыCAN быть модульным испытанием. Они не могут быть осмеяны (как правило, для этого есть несколько структур, например:Кроты.

 17 мая 2012 г., 11:30
Но это излишне для простых случаев. Кроты интегрируются в процесс сборки и доступны только для .net
Решение Вопроса

Тестирование статического метода ничем не отличается от тестирования любого другого метода. Наличие статического метода в качествеdependency внутри другого тестируемого модуля возникают проблемы (как уже упоминалось - вы не можете издеваться / заглушать его с помощью бесплатных инструментов). Но если сам статический метод является модульным, вы можете простоотноситься к нему как к рабочему, надежному компоненту.

В целом, в этом нет ничего плохого (например, он не нарушает модульное тестирование / TDD) статическими методами, когда:

it is simple, input-output method (all kinds of "calculate this given that") it is reliable, by what we mean it's either unit tested by you or comes from 3rd party source you consider reliable (eg. Math.Floor might be considered reliable - using it shouldn't raise "Look out, it's static!" warning; one might assume Microsoft does its job)

Когда статические методы вызовут проблемы и их следует избегать? В основном только тогда, когда они взаимодействуют с /do something you cannot control (или издеваться):

all kind of file system, database, network dependencies other (possibly more complex) static methods called from inside pretty much anything your mocking framework can't deal with on regular terms

Edit: two examples on when static method will make unit testing hard

1

public int ExtractSumFromReport(string reportPath)
{
     var reportFile = File.ReadAllText(reportPath);
     // ...
}

Как вы справляетесь сFile.ReadAllText? Это, очевидно, пойдет в файловую систему для получения содержимого файла, что является основным нет-нет при модульном тестировании. Это пример статического метода с внешней зависимостью. Чтобы избежать этого, вы обычно создаете оболочку вокруг api файловой системы или просто внедряете ее в качестве зависимости / делегата.

2

public void SaveUser(User user)
{
    var session = SessionFactory.CreateSession();
    // ...
}

Как насчет этого? Сессияnon-trivial зависимость. Конечно, это может прийти какISession, но как заставитьSessionFactory вернуть макет? Мы не можем. И мы не можем создатьeasy to detemine Объект сеанса либо.

В вышеописанных случаях лучше вообще избегать статических методов.

 17 мая 2012 г., 17:27
@Pingpong: Не могли бы вы немного расширить?Math.Floor выполняет расчеты - мы издеваемся? Нет, потому что мы знаемMath.Floor(2.5) вернется 2. Когда ввод-выводeasy to determine Вам не нужно что-либо издеваться (или использовать экземпляр). Целыйstatic method makes testing hard Происходит из ситуаций, когда они предоставляют нетривиальные зависимости или имеют побочные эффекты. Смотрите мое редактирование.
 Pingpong17 мая 2012 г., 17:09
Что делать, когда статический метод выполняет вычисления, и вы не можете его высмеять? Требуется ли сделать это методом экземпляра?
 Pingpong17 мая 2012 г., 22:10
Хорошие примеры (1,2). Если мы используем только элементы экземпляра, когда это возможно, зачем нам оба?
 Pingpong17 мая 2012 г., 18:03
Как насчет статического метода - это пользовательский метод, который выполняет длительные вычисления процесса?
 17 мая 2012 г., 21:43
@Pingpong: модульные тесты должны выполняться быстро. Если что-то замедляет их, это, скорее всего, следует абстрагировать. Или просто проведите интеграционный тест (хотя в большинстве случаев вам понадобятся оба).

Вы не можете макетировать статические методы / свойства. Итак, когда вашclassA использует некоторый статический членclassB Вы не можете проверитьclassA в изоляции.

ОБНОВЛЕНИЕ: я не вижу никакой проблемы оборачивания некоторого статического класса в объект. Это не занимает много времени, но позволяет уменьшить сцепление в вашей системе.

Ваш ответ на вопрос