Pull to refresh

Comments 11

Спасибо за замечательную статью!
Интересный инструмент для автоматизации порой довольно рутинных операций. А еще вопрос, много «лишнего» кода генерирует данный иснтрумент Microsoft Moles?
Ну если я правильно понял, то код не лишним оказывается. Так как при релизной компиляции Moles не надо использовать (хотя это конечно дело вкуса). Поэтому и ни как не сказывается на объем кода и быстродействие.
Молес нужен для тестов, и код генерится в тестах. Пофику релизных или не релизных. Объем кода приложения ессно не меняется.
Вы имеете возможность указать для каких именно типов генерировать Mole & Stub классы
Отличная вещь этот Moles и автор кажется человек хороший. :-)
Уже давно используем Moles. Но вот при использовании постоянно есть ощущение неправильности происходящего. Оно то вроде классно — этот runtime instrumenting, но…

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

Если проект пишется «с нуля» или разрабатываются какие-то новые слабо-зависимые компоненты или архитектура системы уже достаточно «слабо-связана», то имхо лучше использовать «обычные» библиотеки мокинга — RhinoMocks и т.д. Ну не покидает ощущение костыля при использовании Moles…
Да, нормальные стабы всегда предпочтительнее молов, но стабы не позволят отвязаться от внешнего environment-а, а вот с этим молы как раз справляются на ура.
Меня скорее смущает runtime instrumenting — ощущение некоторой сюрреалистичности происходящего в тесте :) тестируешь var str = new String(); а String то уже может быть не тот String… :) (пример выдуманный и доведен до абсурда, никак не связанный с реальными кусками кода) Понимаешь что «так надо» и «без этого не протестируешь ибо слишком много зависимостей в старом коде», но это постоянное ощущение «подмены» мне не очень нравится.

Может это мое личное и пора сходить к психологу? :)
Sign up to leave a comment.

Articles

Change theme settings