В .NET TypeMock Isolator и Microsoft Moles позволяют изолировать любой класс, свойство или метод - будь то герметичный, статический, защищенный или не виртуальный. Так что то, что было невозможно издеваться в Moq или Rhino Mocks, теперь уже не так.

У меня всегда была некоторая неприязнь к идее использования интерфейса просто для того, чтобы иметь возможность допускать насмешки, в противном случае существовал бы только конкретный класс. Я не одинок в этом взгляде (см.Вот, Вот, а такжеВот). В последующем подразумевается, что «современным» фреймворкам больше не нужны интерфейсы для тестирования или внедрения зависимостей.

Однако, хотя я не могу говорить о TypeMock Isolator, я могу сказать, что использование Mocks в Microsoft Moles очень медленное. Наличие кода, подобного следующему в модульных тестах, делает скорость теста слишком медленной для частого использования:

MFile.ReadAllLinesString = (s) => csvDataCorrectlyFormatted;
MDirectoryInfo.AllInstances.GetFilesString = (di,fi) => fileInfoArray;
MFileInfo.AllInstances.NameGet = (fi) => "Doesn't Matter";

Я уверен, что если бы тестируемый метод был запрограммирован на интерфейс или абстрактный базовый класс (так, чтобы код файловой системы мог быть абстрагирован в оболочке своего рода), то использование фреймворков, таких как Moq для создания заглушек или насмешек, закончилось бы быстрее , Но затем мы вернулись к ситуации, когда добавили сложность производственного кода для возможности модульного тестирования.

Я склоняюсь к мнению, что Isolator и Moles следует использовать только тогда, когда нельзя издеваться над традиционными инструментами. Тем не менее, я все еще борюсь с понятием добавления сложности производственного кода для тестирования.

Мне любопытно, что думает остальная часть сообщества.

ОБНОВЛЕНИЕ 10/06/10: Говоря, что я борюсь с понятием добавления сложности производственного кода для тестирования, я имею в виду добавление интерфейса (или даже абстрактного класса), когда в противном случае он не нужен, например, при создании конкретного класса. незапечатанные и виртуальные методы подойдут. Последний по-прежнему позволяет швы для тестирования. Даже если позже обнаружится необходимость использования интерфейса для нескольких реализаций, не могли бы они извлечь его из класса? Но если в этом нет необходимости, почему бы не следоватьYAGNI.

Я полностью за принципы SOLID, где они облегчают поддержку архитектуры программы. Я не думаю, что эти принципы должны соблюдаться религиозно в каждом случае. Я думаю, что мантра, «Это всегда зависит», входит в игру много раз. В противном случае каждый остается с каждым конкретным типом, имеющим интерфейс или абстрактный базовый класс, даже если будет только одна реализация.

Наконец, я не говорю, что, поскольку Isolator и Moles позволяют обойти ограничения изоляции в средах на основе динамических прокси-серверов, не следует проектировать архитектуру, чтобы ее можно было поддерживать. Во многих случаях принципы SOLID - это то, что лучше, и, следовательно, Isolator или Moles не понадобятся. Это случаи, когда интерфейс используется исключительно для тестирования, который я ставлю под сомнение. Я поднимаю еще один аспект скорости. Если кто-то выберет использование Isolator и Moles, он, кажется, приносит штраф скорости. Так что я, конечно, не думаю, что они делают динамические фреймворки на основе прокси устаревшими.