Как тестировать код с множеством зависимостей - PullRequest
2 голосов
/ 20 августа 2011

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

class ClassUnderTest  {
    public void SetNoMatchingImage() {
        currentState.State = FSMState.NoMatchingImage;
        ... // Some more logic
        NotifyViews();
    }

    public ViewStatus GetStatus() {
        ...
        if (currentState.State == FSMState.NoMatchingImage)
           return ViewStatus.EmptyScreen;
        ...
    }

    ...
}

Хорошо, так что протестируйте это, япросто хотел бы сделать:

[Test]
public void TestSetNoMatchingImage() {
    ClassUnderTest view = new ClassUnderTest(...);
    view.SetNoMatchingImage();  
    Assert.AreEqual(ViewStatus.EmptyScreen, view.Status); 
}

Но моя проблема здесь в том, что конструктор ClassUnderTest принимает 3 аргумента для неинтерфейсов, которые не могут быть нулевыми, поэтому я не могу легко создать ClassUnderTest.Я могу попытаться создать экземпляры этих классов или заглушить их, но проблема для них та же: каждый из конструкторов принимает аргументы, которые должны быть созданы.И проблема та же для ... и так далее.Результатом, конечно, являются очень большие накладные расходы и большое количество кода, необходимого даже для очень простых тестов.

Есть ли хороший способ справиться с такими случаями, чтобы упростить написание тестовых примеров?

Ответы [ 3 ]

2 голосов
/ 20 августа 2011

У вас будет много ситуаций, подобных этой, когда вы начнете рефакторинг проекта без тестов, если он не был спроектирован с учетом Dependency Injection, а используемая вами среда насмешки не может насмехаться над конкретными классами (такими как NMock).

Как только что упомянул Andriys, Typemock (и moq тоже) может издеваться над конкретными классами, пока у него есть виртуальные члены.

Лично я извлеку интерфейс из каждого из этих трех классов и внедрил бы интерфейсы как часть некоторого рефакторинга, чтобы сделать класс простым для тестирования. Я не могу вспомнить, есть ли в VS рефактор для извлечения интерфейса в 2 клика, что не займет много времени.

1 голос
/ 20 августа 2011

Я бы рекомендовал взглянуть на каркас Typemock Isolator. Согласно книге Роя Ошерова «Искусство модульного тестирования», это лучший выбор при написании модульных тестов для устаревшего кода:

... это единственный [фреймворк], который позволяет создавать заглушки и макеты зависимостей в производственном коде без необходимости вообще его реорганизовывать, экономя ценное время при тестировании компонента.

Ура!

0 голосов
/ 20 августа 2011

Я бы рекомендовал Typemock и решения, предложенные в других ответах.В дополнение к тому, что уже было сказано, Майкл Фезерс написал книгу о шаблонах, с которыми вы сталкиваетесь, под названием «Эффективная работа с устаревшим кодом» -

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/ref=sr_1_1?ie=UTF8&qid=1313835584&sr=8-1

PDF выписка здесь - http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...