Как я могу измерить накладные расходы на насмешливую структуру (TypeMock)?

Question

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

Ссылки? Личный опыт? Детали оценены.

Answer 1

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

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

К сожалению, я не записывал фактические цифры в своих тестах относительно Moq vs TypeMock, но преимущество Moq в производительности очень важно в моем опыте.

Answer 2

IIRC TypeMock использует API-интерфейс Profiler, который, как правило, добавляет довольно много накладных расходов, но должен все же быть быстрее, чем запуск приложения через профилировщик.

NCover также использует API-интерфейс Profiler и, кажется, довольно быстро.

Answer 3

Аарон Дженсен создал тестовый проект и провел некоторые испытания производительности. http://codebetter.com/blogs/aaron.jensen/archive/2008/05/08/mock-framework-benchmarks.aspx

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

Answer 4

Мы используем TypeMock в течение нескольких лет, и по моему опыту нет существенных накладных расходов (я уверен, что накладные расходы, это просто не большая проблема).

Однако из-за характера работы TypeMock есть несколько вещей, которые следует учитывать. Поскольку TypeMock в основном работает, вводя код «на лету», ошибки иногда могут быть очень экзотическими. Ошибки отчетности могут, таким образом, стать немного сложной задачей. Будьте готовы копать в Ил.

Мой опыт в том, что может быть трудно объяснить «средний разработчик», как работает TypeMock. Это быстро усложняется, и даже несмотря на то, что их инструменты Trace делают поиск неисправностей выполнимым, он все еще оставляет немного поддержки.

Кроме того, поскольку TypeMock позволит вам издеваться над чем-либо (кроме mscorlib), вам не нужно добавлять необходимые уровни косвенности к вашему коду. Это особенность, и TypeMock здесь не виноват. Тем не менее, я видел, как многие разработчики пытались решить свои проблемы, издеваясь над местом вместо того, чтобы развязать код. Это не улучшает общее качество кода IMO.