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

Question

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

Ссылки? Личный опыт? Подробности приветствуются.

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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