Moq как вы тестируете внутренние методы?

Question

Сказал мой босс, чтобы использовать Moq и все. Мне это нравится, но кажется, что в отличие от MSTest, mbunit и т. Д. Вы не можете тестировать внутренние методы

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

Я что-то упустил?

Можете ли вы протестировать внутренние методы, используя Moq?

Большое спасибо

Answer 1

Вы можете использовать атрибут InternalsVisibleTo , чтобы сделать методы видимыми для Moq.

http://geekswithblogs.net/MattRobertsBlog/archive/2008/12/16/how-to-make-a-quotprotectedquot-method-available-for-quotpartialquot-mocking-and-again.aspx

Answer 2

Нет ничего плохого в том, чтобы сделать внутренние компоненты видимыми для других классов для тестирования. Если вам нужно проверить внутреннее устройство класса, обязательно сделайте это. Тот факт, что методы не являются общедоступными, не означает, что вы должны игнорировать их и проверять только общедоступные. Хорошо разработанное приложение на самом деле будет иметь большую часть кода, инкапсулированного в ваших классах таким образом, что они не будут публичными. Поэтому игнорирование закрытых методов в вашем тестировании является большой ошибкой ИМХО. Одной из прелестей модульного тестирования является то, что вы тестируете все части своего кода, независимо от того, насколько малы и когда все ваши тесты запущены и работают на 100%, это очень разумное предположение, что когда все эти части собраны вместе, ваш Приложение будет работать правильно для конечного пользователя. Конечно, проверяя, что последняя часть - то, где тесты уровня интеграции входят - что является другим обсуждением. Так что проверь !!!

Answer 3

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

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

Answer 4

С моей точки зрения, насмешка должна использоваться для того, чтобы смоделировать какое-то поведение, от которого мы зависим, но не намерены тестировать. Следовательно:

В: Я что-то упустил? - Нет, вы ничего не упускаете, MOQ не хватает способности высмеивать частное поведение.

В: Можете ли вы протестировать внутренние методы, используя Moq? - Если результат приватного поведения виден публично, то да, вы можете протестировать внутренний метод, но не из-за Moq вы можете его протестировать. Я хотел бы подчеркнуть, что Mock - это не способность к тестированию, а способность к подобному поведению, которое мы не тестируем, а зависим от него.

C: Основное преимущество TDD заключается в том, что ваш код легко изменить. Если вы начнете тестировать внутренние компоненты, тогда код станет жестким и его трудно изменить - Я не согласен с этим комментарием по двум основным причинам: 1: Это не заблуждение новичка, поскольку TDD - это не только способность кодировать быстрее, но и код лучшего качества. Следовательно, чем больше тестов мы можем сделать, тем лучше. 2: Это не делает код более сложным для изменения, если вы можете как-то проверить внутренние методы.

Answer 5

InternalsVisibleTo - ваш друг для тестирования внутренних устройств. Не забудьте подписать свои сборки, и вы в безопасности.

Answer 6

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

Конечно, могут существовать случаи, когда частные методы должны тестироваться изолированно, но 99% распространенных случаев - это то, что частные методы тестируются неявно, потому что они заставляют открытые методы пройти свои тесты. Публичные методы вызывают приватные методы.

Частные методы существуют по причине. Если они не приводят к внешнему тестируемому поведению, тогда они вам не нужны.

Проведены ли какие-либо публичные тесты, если вы просто удалите их? Если да, то они уже проходят тестирование. Если нет, то зачем они вам? Узнайте, для чего они вам нужны, а затем выразите это в тесте на общедоступный интерфейс.

Основным преимуществом TDD является то, что ваш код легко изменить. Если вы начнете тестировать внутренние компоненты, тогда код станет жестким и его трудно изменить.