В этом посте мы попытаемся проанализировать SharePoint и модульное тестирование.

Введение

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

Какую бы модель развития мы ни выбрали, мы столкнемся с некоторыми проблемами и поломаем голову до мозга костей. Некоторые даже говорят, что при разработке SharePoint не учитывалась возможность тестирования. Тем не менее, давайте рассмотрим различные способы, которые мы можем исследовать.

Вариант 1: избегать модульного тестирования

Этот вариант довольно радикален и прост. От того, сможем ли мы жить с этим, зависит наше нет.

Вариант 2: используйте сторонние инструменты, предназначенные для SharePoint

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

Вариант 3: перенос объектов SharePoint

Когда мы разрабатываем с использованием .NET Framework и хотим написать наши различные тесты, очень часто используются такие инструменты, как Moq, для создания поддельных объектов, чтобы легко изолировать то, что мы хотим протестировать. Теперь, с SharePoint, наша главная проблема заключается в коде, который зависит от SharePoint. Использование Moq для имитации SharePoint в большинстве случаев заведет нас в тупик. Классы SharePoint часто запечатаны, а некоторые объекты не могут быть созданы без контекста HTTP. Может быть, нам удастся смоделировать несколько вещей, но результат не будет удовлетворительным и, вероятно, будет грязным.

Одним из способов обхода этой проблемы является перенос значений различных объектов SharePoint, которые нам нужны, в классы или структуры, которые мы контролируем и можем легко имитировать. Это потребует создания дополнительных классов, но если мы будем использовать эти различные оболочки, это может упростить модульное тестирование.

Вариант 4: создать еще один слой

Этот вариант использует «Вариант 3» и позволяет нам создать еще один слой между нашим кодом и SharePoint. Это означает, что вместо прямого использования различных API-интерфейсов SharePoint мы создаем один или несколько объектов (Службы, Прокси или называем их как угодно) ), с которыми мы будем работать. Затем эти объекты будут работать с различными API SharePoint, напрямую или через репозитории, в зависимости от того, как мы хотим реализовать эту концепцию, и возвращать завернутые объекты.

Это решение означает, что мы можем сконцентрировать использование объектов SharePoint в ограниченной области и отделить наш код от API SharePoint. Таким образом, это означает, что в таких вещах, как Приемники событий или код, лежащий в основе Шаблоны элементов управления, вместо использования классов SharePoint мы используем наши разные Службы. Это делает наш код более тестируемым и позволяет избежать дублирования кода.

Однако большинство методов, предоставляемых объектами SharePoint, не имеют возвращаемого значения. Итак, если у нас есть Служба, которая взаимодействует с Репозиторием, как мы можем узнать, что SharePoint не удалось или удалось выполнить запрошенную операцию? Что ж, к сожалению, приходится искать обходные пути. Например, когда мы добавляем SPItem в SPList, мы можем подсчитать количество элементов до и после операции и проверить, существует ли элемент в обновленной коллекции, и вернуть логическое значение в зависимости от сценария. Это приводит к лишнему коду и увеличению времени операции, но у нас будет ответ.

Конечно, этот вариант может привести к чрезмерным инженерным проблемам, и всегда будет точка, в которой мы столкнемся с объектами SharePoint. Мы также должны проявлять особую осторожность при обработке объектов SPContext, SPSite и SPWeb, потому что это может привести к серьезным исключениям, если мы сделаем это без осторожности.

Вариант 5: создать консольное приложение

На самом деле это не модульное тестирование. Однако мы можем представить себе создание небольшого консольного приложения с использованием C# или PowerShell, которое будет проверять после развертывания нашего пакета, были ли наши различные функции установлены и активированы, или если наши списки находятся в нужном месте. Он включает в себя всю установку SharePoint и «реальные» данные.

Вывод

В этой статье мы изучили некоторые варианты, которые у нас есть, когда мы хотим модульное тестирование против SharePoint. Мы видим, что модульное тестирование в таком случае не очень просто и может принести нам боль и страдания, а может быть, и больше, чем если бы мы делали это с другой платформой или фреймворком. Тем не менее, у нас есть несколько возможностей, которые могут сделать нас более безопасными в нашем развитии. Мы должны решить, какое решение является лучшим, в зависимости от того, чего мы хотим достичь, и признать, что некоторые вещи лучше всего проверить вручную, и помнить старую добрую вещь «попробуй… поймай». здесь для нас.

Последнее слово

Если вам понравилась эта статья, вы можете поддержать и помочь мне на Patreon! Это было бы круто! В противном случае вы можете найти другие мои посты на Medium и Tumblr. Вы также узнаете больше обо мне на моем личном сайте. До следующего раза, счастливой головной боли!