Спорная альтернатива для вас - не используйте насмешки!
Вместо этого проведите интеграционное тестирование, потому что действительно, как только вы используете OM OM, именно это вы и делаете.
Поместите как можно больше своей логики в библиотечные сборки, которые могут работать вне контекста запроса (конструктор перегрузки для передачи либо в HttpContext, либо в SPWeb).
Настройте сервер / сайт (желательно виртуальную машину, чтобы вы могли легко выполнить откат и создавать новые экземпляры) только для модульных тестов и запускайте их. ( VMWare Server свободен)
Если вы работаете с непрерывной сборкой, вы можете настроить ее на автоматический запуск и выдачу результатов. В качестве альтернативы можно использовать некоторую магию пакетного файла с открытым исходным кодом nUnit или выбранный вами инструмент для запуска тестов, как только новый файл DLL будет скопирован на шаге PostBuild.
Недостатки
У вас есть немного работы по настройке
данные для ваших тестов (хотя это
гораздо больше, чем издеваться
работает?)
Не все можно проверить таким образом
Может потребоваться немного больше времени для запуска, но если проблема является частью непрерывной сборки, это проблема?
В команде требуется больше дисциплины, чтобы не наступать на пальцы других людей.
Преимущества
Ваше тестирование на реальном SharePoint OM со всеми его непонятными несоответствиями и особыми случаями (если вы были недобры, вы можете назвать их ошибками;)
Кто знает, какие части поведения OM могут незаметно измениться при появлении новых пакетов обновления / накопительных обновлений, это должно помочь отследить любые критические изменения.
- Когда появится SharePoint 2010, вы сможете запускать свои тесты как для 2007, так и для 2010 года, посмотрите, что изменилось, убедитесь, что ваша библиотека работает с обеими версиями (если это соответствует вашему проекту)
Компромиссы для всех проектов различны, но для моих проектов я предпочитаю безопасность знания того, что я проверяю на реальных вещах - назовите меня старомодным, если хотите!