Мой босс сказал использовать Moq, и все. Мне это нравится, но кажется, что в отличие от MSTest или mbunit и т. д., вы не можете тестировать внутренние методы.
Поэтому я вынужден опубликовать некоторую внутреннюю реализацию в моем интерфейсе, чтобы я мог ее протестировать.
Я что-то упускаю?
Можете ли вы протестировать внутренние методы с помощью Moq?
Большое спасибо
Вы можете использовать атрибут InternalsVisibleTo, чтобы методы, видимые для Moq.
Отн. ="noreferrer">http://geekswithblogs.net/MattRobertsBlog/archive/2008/12/16/how-to-make-a-quotprotectedquot-method-available-for-quotpartialquot-mocking-and-again.aspx
Нет ничего плохого в том, чтобы сделать внутренние компоненты видимыми для других классов для тестирования. Если вам нужно протестировать внутренности класса, обязательно сделайте это. Тот факт, что методы не являются общедоступными, не означает, что вы должны игнорировать их и тестировать только общедоступные. Хорошо спроектированное приложение на самом деле будет иметь большую часть кода, инкапсулированного в ваши классы таким образом, что они не будут общедоступными. Так что игнорирование непубличных методов в вашем тестировании - большая ошибка ИМХО. Одна из прелестей модульного тестирования заключается в том, что вы тестируете все части своего кода, независимо от того, насколько они малы, и когда все ваши тесты запущены и работают на 100 %, вполне разумно предположить, что, когда все эти части собраны вместе, ваш приложение будет работать правильно для конечного пользователя. Конечно, проверка этой последней части - это то, где вступают тесты уровня интеграции - это другое обсуждение. Так что тестируйте!!!
Если у вас много кода, который не тестируется общедоступными методами, возможно, у вас есть код, который следует переместить в другие классы.
Как сказано в другом ответе, для этого вы можете использовать атрибут InternalsVisibleTo. Но это не значит, что вы должны это делать.
С моей точки зрения, Mocking следует использовать для имитации некоторого поведения, от которого мы зависим, но не собираемся его тестировать. Следовательно:
В: Я что-то упустил? - Нет, вы ничего не упускаете, в MOQ отсутствует возможность издеваться над личным поведением.
В: Можете ли вы протестировать внутренние методы с помощью Moq? - Если результат частного поведения виден публично, то да, вы можете протестировать внутренний метод, но вы не можете протестировать их из-за Moq. Я хотел бы отметить здесь, что Mock — это не способность тестировать, а скорее способность к аналогичному поведению, которое мы не тестируем, но от которого зависим.
C: Основное преимущество TDD заключается в том, что ваш код становится легко изменить. Если вы начинаете тестировать внутренности, то код становится жестким и трудно поддающимся изменениям — я не согласен с этим комментарием по двум основным причинам: 1: Это не заблуждение новичка, поскольку TDD — это не только возможность писать код быстрее, но и также более качественный код. Следовательно, чем больше тестов мы сможем сделать, тем лучше. 2: Это не усложняет изменение кода, если вы каким-то образом можете протестировать внутренние методы.
Ваше первоначальное предположение о необходимости тестирования внутреннего метода является распространенным заблуждением новичков относительно модульного тестирования.
Конечно, могут существовать случаи, когда частные методы следует тестировать изолированно, но в 99% случаев частные методы тестируются неявно, потому что они заставляют общедоступные методы пройти свои тесты. Публичные методы вызывают приватные методы.
Частные методы существуют по какой-то причине. Если они не приводят к внешнему тестируемому поведению, то они вам не нужны.
Какие-нибудь из ваших общедоступных тестов не пройдут, если вы просто удалите их? Если да, то они уже проходят испытания. Если нет, то зачем они вам? Узнайте, для чего они вам нужны, а затем выразите это в тесте на публичном интерфейсе.
Основное преимущество TDD заключается в том, что ваш код становится легко изменить. Если вы начинаете тестировать внутренности, то код становится жестким и его трудно изменить.
InternalsVisibleTo — ваш друг для тестирования внутренних компонентов. Не забудьте подписать свои сборки, и вы в безопасности.
