При разработке unit тестов в Visual Studio часто хочется создать какой-то базовый клас для тестирования базовой лоники. Например у нас есть такой класс:

 

        [TestClass]
        public class PersonTestBase
        {
            [TestMethod]
            public
virtual void GetNameTest()
            {

                //...
            }
        }

 и его класс наследник:
        [TestClass]
    public class CustomerTest: PersonTestBase
    {
        [TestMethod]
        public override void GetNameTest()
        {
            base.GetNameTest();
        }
    }

 Плюсы такого подхода:

  • полная поддержка визуальных средств Visual Studio (Test List Editor);
  • простота реализации.
Минусы:
  • избыточность кода;
  • создание наследника является по сути copy&paste.
Сразу необходимо заметить, что PersonTestBase и CustomerTest должны находится в одной сборке, иначе тесты в PersonTestBase работать не будут - это ограничение unit тестов. Подробнее смотрите в msdn. Кроме описанных в msdn способов можно поступить так:
  •  создаётся два проекта: BaseTests и CustomTests;
  • в проект CustomTests добавляются необходимые файлы из BaseTests таким образом: Project -> Add Existing Item -> Выбираем необходимые файлы -> Add As Link.
Таким образом физически файлы находятся в разных проектах, но при компиляции необходимые классы оказываются в одной сборке.
 
 Теперь пришло время изменить наш CustomerTest.
        [TestClass]
    public class CustomerTest: PersonTestBase
    {
        [TestMethod]
        public override void CustomerTestMethod()
        {
            //...
        }
    }
Мы добавили новый, специфический для Customer, метод и удалили переопределения метода из базового класса, т.к. его функциональность нас полность устраивает. Что мы из этого получили:
  • фактически, в классе у реализоано 2 тестовы метода: один перешел из базового класса и один мы реализовали сами.
  • Visual Studio Test List Editor говорит что у нас только один тетовый медов - метода из бащового класс не отображается и, соответственно, не запускается.
Обидно, но не смертельно. На помощь нам приходит штатная утилита MSTest , которая решает все, или почти все, наши проблемы.
Плюсы такого метода:
  • мы избавились от минусов предыдущего метода;
Минусы:
  • нету интеграции с Visual Studio. 

В начале этого месяца на CodePlex появился новый проект - Oxite. Некоторые сразу его восприняли как аналог WordPress - но, как мне кажется, судить об этом ещё рано. Главная особенность заключается, конечно же, в том, что он написан на ASP.NET MVC Beta. Первые ощущениея при его испольщзовании - работает быстрее Blog Engine. Сразу захотелось увидеть его в действии в боевых условиях, в данный момент пока это только сайт http://visitmix.com/. К слову на Mix 09 будет официально представлен Oxite.

В данный момент проект проект не обладает широкой функциональностью, но уже сейчас можно создавать блоги, делать комментарии, работает RSS, поиск, есть поддержк MetaWebLog API (будет интересна тем, кто пользуется Windows Live Writer). Из недостающего- хотется поддержку тем, облака тегов икатегорий - тогда можно будет уже задумываться о переходе с Blog Engine, хотя, никто не мешает самому дописать недостающую функциональность.

 С точки зрения разработчика - очень хороший пример как правильно писать на ASP.NET MVC. Как минимум - хороший Starter Kit, максимум - поживём - увидем что из этого получится. Может действительно появится достойная замена WordPress на ASP.NET?