Hungry Mind , Blog about everything in IT - C#, Java, C++, .NET, Windows, WinAPI, ...

TypeMock.NET

По словам моего сотрудника, человека с приличным опытом, TypeMock.NET - лучшее решение для генерации (точнее сказать - просто решение, но об этом позже) Mock-объектов и использования их в юнит тестах.

Традиционные Mock фреймворки имеют определенные требования к объектной модели, обусловленные принципами функционирования - сабклассинг и динамическая генерация кода. Эти требования нередко заставляют проектировать с учетом необходимости юнит тестирования посредством Mock-объектов, что негативно сказывается на конечном результате и удобстве использования. Некоторые вещи вообще с трудом подлежат юнит тестированию, например, классы, использующие внешние статические методы. Решается либо условной компиляцией (далеко не уйдешь) либо перепрограммированием механизма взаимодействия объектов (порядочное усложнение существующего кода).

Итак, почему же "#1 Mocking Framework"? Лучше всего сразу посмотреть на возможности TypeMock.NET, который доступен в 3-х редакциях - Community (бЭсплатно), Professional и Enterprise (соответсвенно, за денюжку).

Если пройтись по списку фич, можно заметить такие интересные и, на первый взгляд, невозможные вещи, как "mock all types, including sealed and internal classes", "fake any method", "mock third-party types, including types in the .NET framework". Нам заявляют, что TypeMock способен подделать поведение любого объекта, в т.ч. его статических методов!

Банальнейший пример демонстрирует, что sealed класс SqlConnection начинает вести себя так, как ему приказано! Шокирующих примеров хватает.

Досих пор меня мучил главный вопрос - как это работает?! Парочка часов скитаний по сети увенчалась успехом! Итак айнц, цвай, драй. И все стало на свои места.

Хитрое решение - перехватывать события .NET приложения (например, вызов метода) с помощью публично доступного Profiler API (на этом, кстати, построены все профайлеры .NET приложений) и подменять исходное поведение требуемым. Хитрое, но не идеальное, т.к. возникают проблемы с отладкой юнит тестов.

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

6 коммент.:

Анонимный комментирует...

"Эти требования нередко заставляют проектировать с учетом необходимости юнит тестирования посредством Mock-объектов, что негативно сказывается на конечном результате и удобстве использования."
Наоборот! Необходимость тестирования заставляет фокусироваться на интерфейсе. Потому простота тестирования очевидно ведет к простоте использования.

"Некоторые вещи вообще с трудом подлежат юнит тестированию, например классы, использующие внешние статические методы."
Отрыжка структурного подхода.

Анонимный комментирует...
Этот комментарий был удален администратором блога.
Unknown комментирует...

Необходимость тестирования не должна ничего заставлять.

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

Второй момент - пересыщение программы парами IMyInterface:MyInterfaceImpl, состоящими в отношении 1:1. При этом существенно усложняется навигация по солюшену, возростает количество сборок. Иногда приводит даже к маразму - выделение интерфейса с immutable класса.
Я всегда говорю: использование интерфейсов должно описываться отношением SUPPORTS-A, а не IS-A.
Ты видел в BCL хотя бы одну пару IMyInterface - MyInterfaceImpl?

Лепра?

Анонимный комментирует...

Ну если надо писать юнит-тесты на чужой готовый код, тогда это все оправдывает.

vansickle комментирует...

"Чаще всего юнит тесты пишут на готовый код"

Какая глупость, читайте http://en.wikipedia.org/wiki/Test-driven_development, . Если юнит-тестов к унаследованному коду нет, то постфактум ничего вы к нему не прикрутите, integration/acceptance - тесты - да, возможно, а вот unit тесты никак.

Unknown комментирует...

Ссылка не меняет того, что юнит тесты чаще пишутся после кода.
И с помощью TypeMock.NET юнит тесты можно "прикрутить" к чему угодно.

Отправить комментарий

Copyright 2007-2011 Chabster