В .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: Говоря, что я борюсь с понятием добавления сложности производственного кода ради тестирования, я имею в виду добавление интерфейса (или даже абстрактного класса). ) когда это не нужно, например, когда конкретный класс незапечатан, а методы - виртуальными. Последний по-прежнему позволяет швы для тестирования. Даже если позже обнаружится необходимость использования интерфейса для нескольких реализаций, не могли бы они извлечь его из класса? Но если в этом нет необходимости, почему бы не следовать ЯГНИ .
Я - за принципы SOLID, где они упрощают поддержку архитектуры программы. Я не думаю, что эти принципы должны соблюдаться религиозно в каждом случае. Я думаю, что мантра, «Это всегда зависит», входит в игру много раз. В противном случае один остается с каждым конкретным типом, имеющим интерфейс или абстрактный базовый класс, даже если будет только одна реализация.
Наконец, я не говорю, что, поскольку Isolator и Moles позволяют обойти ограничения изоляции в средах на основе динамических прокси-серверов, не следует разрабатывать архитектуру, чтобы ее можно было поддерживать. Во многих случаях принципы SOLID - это то, что лучше, и, следовательно, Isolator или Moles не понадобятся. Это случаи, когда интерфейс используется исключительно для тестирования, который я ставлю под сомнение. Я поднимаю еще один аспект скорости. Если кто-то выберет использование Isolator и Moles, он, кажется, приносит штраф скорости. Так что я, конечно, не думаю, что они делают динамические фреймворки на основе прокси устаревшими.