Unit-тесты для SharePoint

Снова о unit-tests?


Да, я уже рассказывал о том, как “правильно” писать юнит-тесты для SharePoint, однако сегодня наткнулся на одну интересную разработку, речь о которой пойдёт далее.

В состав Pex входит инструментарий для создания stub-объектов под названием Mole, он умеет работать с закрытыми для наследования объектами, на коих строится объектная модель SharePoint.

Если вы не знаете что такое Pex

В компании Microsoft есть подразделение, занимающееся научными разработками, называется оно Microsoft Research, подробнее узнать о том, чем же занимается это подразделение можно узнать здесь: http://research.microsoft.com/en-us/research/default.aspx

Одно из разработок данного подразделения – средство white-box тестирования для .NET под названием Pex. Разработка доступна для скачивания: http://research.microsoft.com/en-us/downloads/d2279651-851f-4d7a-bf05-16fd7eb26559/.

Конечно же концептуально Pex противоречит некоторым аспектам юнит-тестирования, т.к. проверяет как написан код, а не что он должен делать.

Насколько известно для SharePoint удобно писать лишь интеграционные тесты, которые помогут вам убедится, в том, что решение благополучно “прилунилось” и проверить, что вся необходимая логика исполняется на “живых” объектах SharePoint.

Однако во многих случаях хочется избавиться от всех инфраструктурных накладок интеграционного тестирования (производительность: я не хочу уходить пить кофе каждый раз при запуске тестов, обновление данных и проч.) и проводить полноценное модуль тестирование в изолированной среде, что обычно и позволяют делать многочисленные фреймворки для создания “тестовых двойников”, примеры для .NET:

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

Пример работы с Mole

Предположим нам необходимо протестировать некоторый участок кода:

public void UpdateTitle(SPItemEventProperties properties) {
    using (SPWeb web = new SPSite(properties.WebUrl).OpenWeb()) {
        SPList list = web.Lists[properties.ListId];
        SPListItem item = list.GetItemById(properties.ListItemId);
        item["Title"] = item["ContentType"];
        item.SystemUpdate(false);
    }
}

Для этого нам необходимо будет произвести ряд действий для генерации тестового проекта, которые я опущу (они подробно описаны в литературе на которую я ссылаюсь). Больше всего интересует код, который будет заниматься э(mole)яцией типов SharePoint:

string url = "http://foo";
// с помощью рефикса MS мы подскажем исполняющей среде, что данный тип э(mole)ирует // SPItemEventProperties и что по вызову свойства WebUrl
// (заметьте что Get свойства опять же опрделен специфичностью синтаксиса) необходимо // будет вернуть заданную нами строку
var properties = new MSPItemEventProperties {
    WebUrlGet = () => url
};

Аналогично и для остальных объектов:

MSPSite.ConstructorString = (site, _url) => {
    new MSPSite(site);
};

new MSPSite(site) {
    OpenWeb = () => new MSPWeb()
};

Так будет выглядеть пример Assert’ов

ListsGet = () => new MSPListCollection {
    ItemGetGuid = id => {
        Assert.IsTrue(listId == id);
        return new MSPList();
    }
}

Думаю данных примеров будет достаточно, для того, чтобы понять, что достойной альтернативы TypeMock Isolator пока нет, однако, с точки зрения сравнения подходов к решению проблемы с промышленной и академической стороны Mole очень интересен.

Материалы

Статья об использовании Mole: http://research.microsoft.com/en-us/projects/stubs/stubstutorial.pdf

Статья о тестировании SharePoint с помощью Mole и Pex: http://research.microsoft.com/en-us/projects/pex/pexsharepoint.pdf


REPL WebPart для SharePoint

Intro

logoСегодня я расскажу о прототипе первого компонента под ярлычком Sapphire. Это REPL WebPart. Эта веб-часть предназначенная для производства оперативных изменений на серверной стороне SharePoint, так же для удаленного исполнения скриптов и тестирования некоторых кусков кода.

PreBody

Производство данной веб-части было инициированно в довольно таки частых потребностях исполнения серверного кода с достаточной оперативностью, в недоступности средств разработки под рукой.

Здесь есть небольшая презетнация, в которой я постарался отобразить принципы работы Repl WebPart:

В добавок к слайдам расскажу о том, что веб-часть представляет собой классический хостинг Dynamic Languages Runtime языков, пока из которых доступен только Python.

Body

Далее хотелось поговорить о том, как же всё это у меня получилось, итак проект включает в себе несколько основных модулей:

  • Веб-часть и контролы представления
  • Хостинг языков

Далее о них поподробнее

Language Hosting

В связи с тем, что языков, которые я захочу реализовать в данном проекте является неограниченное множество, то конечно же мне необходима абстрактная фабрика для их создания, которая будет скрывать иерархию всех доступных языков и инкапсулировать их под интерфейсом:

  public interface ILanguagesFactory
  {
    ILanguage Create(string name);
  }

  public interface ILanguage
  {
    string Name { get}

    object Execute(string input);

    void SetVar(string name, object value);
    
    object GetVar(string name);
  }

Отлично, далее к нашему проекту присоединяются сборки, необходимые для имплементации скриптовых языков:

Всё готово для того, чтобы реализовать Python, как среду для исполнения кода, отлично, приступим:

  public class PythonLanguage : ILanguage
  {
    private readonly ScriptScope _scope;
    
    public string Name
    {
      get { return «Python»}
    }

    public PythonLanguage()
    {
      _scope = Python.CreateEngine().CreateScope();
    }

    public object Execute(string input)
    {
      ScriptSource source = _scope.Engine.CreateScriptSourceFromString(input);
      return source.Execute(_scope);
    }
  }

Далее немного усложним задачу, в связи с тем, что нам будет необходимо реализовать контекст для работы с SharePoint, выглядеть это должно примерно так:

    [Test]
    private void python_should_assume_sharepoint_variables()
    {
      SPWeb fakeWeb = Isolate.Fake.Instance<SPWeb>();
      Isolate.WhenCalled(() => fakeWeb.Title).WillReturn(«I’m fake web»);
      var python = _factory.Create(«Python»);
      python.SetVar(«__x__»«123»);
      python.SetVar(«__web__», fakeWeb);
      python.Execute(«__x__ = __web__.Title»);
      var x = (string)python.GetVar(«__x__»);
      Assert.AreEqual(x, «I’m fake web»);
    }

Для работы с объектами SharePoint в из IronPython, нам необходимо добавить несколько библиотек:

      _scope.Engine.Runtime.LoadAssembly(typeof(string).Assembly);
      _scope.Engine.Runtime.LoadAssembly(typeof(Uri).Assembly);
      _scope.Engine.Runtime.LoadAssembly(typeof(SPList).Assembly); 

Это будет основой нашей работы с динамическими языками

WebPart + WebControls

Создадим проект с помощью SPVisualDev, добавим в него feature, внутри которой создадим веб-часть Repl WebPart, всё остальные действия стандартные, однако есть небольшой нюанс, нам нужен будет объект, с помощью которого можно будет выводить строковые значения после исполнения. Я решил создать для этих целей объект с классическим названием Console, его реализация предельна проста:

  public class Console
  {
    private readonly StringBuilder _messageBuilder = new StringBuilder();

    public void Write(object message)
    {
      _messageBuilder.Append(message);
    }

    public void WriteLine(object message)
    {
      _messageBuilder.AppendLine(message.ToString());
    }

    public string Message
    {
      get
      {
        return _messageBuilder.ToString();
      }
    }
  }

Мы будем передавать его в среду исполнения языков, а после исполнения кода опрашивать его свойство Message и выводить его содержимое в нашу веб-часть.

EndBody

Все исходники проекта доступны на github: http://github.com/butaji/Sapphire

Так же предварительную версию Sapphire.Environment (решение поставляется в WSP) можно слить на CodePlex: http://sapphire.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=34895


Делаем блог на ASP.NET MVC, следуя принципам DDD, TDD

Товарищ Vinay ведёт отличный блог, посвещённый тематике разработке на основе предметной области. Сегодня он начал серию постов, в которых собирается рассмотреть пример разработки блога на ASP.NET MVC.

solution_thumb[1] Для того, чтобы следовать его урокам вам понадобятся следующие инструменты:

ASP.NET MVC – здесь всё понятно.

NHibernate и FluentNHibernate – наш объектно-реляционный преобразователь.

StructureMap – для реализации Dependency Injection.

xUnit.Net – для TDD.

MoQ – делаем МОКи.


Пример TDD с использованием IoC-контейнера и Mock-фреймврка

Jarod Ferguson выступал с этим докладом на 2009 Boise Code Camp и выложил слайды и примеры кода. Советую ознакомиться.

Чуть подробнее читать здесь:

http://elegantcode.com/2009/03/29/boise-code-camp-test-driven-development-with-ioc-and-mocks/