Поблочное тестирование и разработка SharePoint
Основным недостатком является потенциальная уязвимость к атакам - например, злонамеренный источник теперь может заполнить ваш веб-сервер сообщениями размером до 2 ГБ и потенциально привести к его снижению.
Конечно, разрешение сообщений объемом 2 ГБ также создает некоторую нагрузку на ваш сервер с точки зрения потребления памяти, поскольку эти сообщения необходимо собирать в памяти полностью (если вы не используете потоковые протоколы в WCF). Если у вас есть 10 клиентов, отправляющих вам сообщения размером 2 ГБ, вам понадобится много оперативной памяти на вашем сервере! : -)
Кроме этого, я не вижу никаких реальных проблем.
Марк
5 ответов
Спорная альтернатива для вас - не используйте mocks!
Вместо этого проводите интеграционное тестирование, потому что на самом деле, как только вы используете OM SharePoint, вы делаете именно это.
Поместите как можно больше своей логики в сборки библиотеки, которые могут запускаться вне контекста запроса (конструктор перегрузки для передачи в HttpContext или SPWeb).
Настройте сервер / сайт (желательно виртуальную машину, чтобы можно было откатиться и легко создать новые экземпляры) только для модульных тестов и запустить их. ( Сервер VMWare бесплатен)
Если вы запускаете непрерывную сборку, вы должны иметь возможность настроить ее на автоматический запуск и отчет о результатах. данные для ваших тестов (хотя это гораздо больше, чем насмешки работает?)
Не все можно протестировать таким образом.
Может потребоваться немного больше времени для запуска, но если запуск в рамках непрерывной сборки, является ли это проблемой?
Требуется больше дисциплины в команде, чтобы избежать перехода на пальцах других людей.
Преимущества
Ваше тестирование на реальном SharePoint OM со всеми его сбивающими с толку несоответствиями и особыми случаями (если вы были недобры, вы можете назвать их ошибками;)
Кто знает, какие части Поведение OM может незначительно измениться, когда появятся новые пакеты обновления / кумулятивные обновления, это должно помочь выявить любые критические изменения.
- Когда появится SharePoint 2010, вы сможете запускать свои тесты как для 2007, так и для 2010, посмотреть, что изменилось, внести убедитесь, что ваша библиотека работает с обеими версиями (если это соответствует вашему проекту)
Компромиссы для всех проектов различны,но для своих проектов я предпочитаю безопасность, зная, что я тестирую на реальном - называйте меня старомодным, если хотите!
Насколько мне известно, нет никого, кроме Typemock Isolator для SharePoint, о котором вы упомянули. Модульное тестирование SHarePoint, как известно, сложно.
Эндрю Вудворд - большой поклонник TDD и SharePoint - посетите его сайт здесь: http://www.21apps.com/agile/unit-testing-sharepoint-getting-into-the-object-model/
Я записал веб-трансляцию о модульном тестировании SharePoint. Это также описано на SharePointDevWiki.com .
Кажется, что JustMock от Telerik также можно использовать. Он также может имитировать закрытые классы, статику и так далее.