При разработке 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. 

Comments

Dmytro Shteflyuk Ukraine

Tuesday, December 23, 2008 4:04 PM

Dmytro Shteflyuk

Шрифт текста и списков разный: img.skitch.com/...3-jfh9hhwccqk9yskrqg5j6js9xe.png
И еще -- в русском языке нету слова "нету".

ЗЫ. В RSpec (спеки для руби) есть такое понятие, как shared specs:

describe "all editions", :shared => true do
  it "should behave like all editions" do
  end
end

describe "SmallEdition" do
  it_should_behave_like "all editions"

  it "should also behave like a small edition" do
  end
end

describe "LargeEdition" do
  it_should_behave_like "all editions"

  it "should also behave like a large edition" do
  end
end

Igor Ukraine

Tuesday, December 23, 2008 4:55 PM

Igor

Вчера нарвался на штуку под названием Pex ( http://research.microsoft.com/en-us/projects/Pex/ ). Не совсем по теме, но приблизительно в ту сторону Smile Правда, есть плохое ощущение что ее final релиз станет платным...

Mike Chaliy Ukraine

Friday, February 18, 2011 3:58 PM

Mike Chaliy

Блин ну есть же композиция, нахрена лепить это наследование. Оно же вообще не читается. Чтобы понять кто куда и что тестит приходится лазить по иерархии тестов. Вверх-вниз.

Comments are closed