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

Question

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

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

Answer 1

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

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

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

Answer 2

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

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 в основном работает путем внедрения кода на лету, ошибки иногда могут быть очень экзотическими.Таким образом, сообщение об ошибках может стать довольно сложной задачей.Будьте готовы покопаться в IL.

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

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