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

Question

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

Как и в книге, которую я читаю о MVC, автор использует фреймворк Moq.

Итак, автор сначала создает интерфейс IFormAuthentication.

Записывает некоторые методы, а затем создает WrapperClass, который реализует эти методы, а затем записывает фактический код для методов (т. Е. Выход из системы).

Итак, в Moq он просто использует интерфейс. Так что это имеет смысл для меня, но поправьте меня, если я ошибаюсь.

Он делает это, потому что хочет, чтобы moq сделал фальшивый макет, используя интерфейс? Затем в приложении MVC он поднял его так, что если интерфейс имеет значение null, он создаст новый класс-оболочку.

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

Так что, надеюсь, я понял это правильно.

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

Вместо этого мы заставим Moq сделать это, а затем он перейдет к Moq MembershipProvider, и он создаст все эти вещи.

Итак, мои вопросы, как он узнал? Например, как, с одной стороны, вы не можете использовать методы FormsAuthentication таким образом, но вы можете использовать MembershipProvider?

Я даже не думаю, что вы можете сделать, как просто членство, это должен быть MembershipProvider.

Так откуда мне взять эту информацию? Как я хочу сделать мой SMTP (MailMessage), и я хочу знать, должен ли я написать интерфейс и затем обертку или я могу сделать то же самое, что MembershipProvider?

Я не уверен, что не знаю, как сказать.

Спасибо

Answer 1

Причина, по которой автор не извлек интерфейс для MembershipProvider, заключается в том, что он уже является абстрактным классом, поэтому он уже отлично работает как Test Double.

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

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

Подробнее о тестовых двойниках можно прочитать в превосходных тестовых таблицах xUnit .