Подтвердить что ты не робот

Тестирование устройства. Неплохая ли форма unit test вызывает другие модульные тесты

У меня есть unit test, называемый TestMakeAValidCall(). Он проверяет мое телефонное приложение на действительный вызов.

Я собираюсь написать еще один тест под названием TestShowCallMessage(), который должен иметь действительный вызов, сделанный для теста. Это плохая форма, чтобы просто вызвать TestMakeAValidCall() в этом тесте?

Для справки это мой тест TestMakeAValidCall().

    [TestMethod]
    public void TestMakeAValidCall()
    {
       //Arrange
        phone.InCall = false;
        phone.CurrentNumber = "";
        // Stub the call to the database
        data.Expect(x => x.GetWhiteListData()).
            Return(FillTestObjects.GetSingleEntryWhiteList());
        // Get some bogus data
        string phoneNumber = FillTestObjects.GetSingleEntryWhiteList().
            First().PhoneNumber;
        // Stub th call to MakeCall() so that it looks as if a call was made.
        phone.Expect(x => x.MakeCall(phoneNumber)).
            WhenCalled(invocation =>
                       {
                           phone.CurrentNumber = phoneNumber;
                           phone.InCall = true;
                       });

       //Act
        // Select the phone number
        deviceControlForm.SelectedNumber = phoneNumber;
        // Press the call button to make a call.
        deviceMediator.CallButtonPressed();

       //Assert
        Assert.IsTrue(phone.InCall);
        Assert.IsTrue(phone.CurrentNumber == phoneNumber);
    }
4b9b3361

Ответ 1

Переустановите настройку на другой метод и вызовите этот метод из обоих тестов. Тесты не должны вызывать другие тесты.

Ответ 2

IMHO, вы должны сделать одно из следующего:

  • Создайте метод, который возвращает действительный вызов, и используйте его отдельно для обоих тестов (а не для вызова другого)
  • Отметьте действительный вызов ShowCallMessageTest

Ответ 3

Я думаю, что это плохая идея. Вы хотите, чтобы ваш unit test тестировал только одну вещь и только одну вещь. Вместо того, чтобы создавать вызовы через свой другой тест, извините вызов и передайте его в качестве аргумента.

Ответ 4

Чтобы предложить встречную точку:

Я твердо верю, что хорошо спроектированные unit test должны зависеть друг от друга!

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

Мы реализовали эту идею в расширении JExample для JUnit. Пока нет портов С#, хотя есть порты для Ruby и Smalltalk и... последний выпуск PHPUnit взял обе наши идеи: зависимости и повторное использование арматуры.

PS: люди также используют его для Groovy.

Ответ 5

A unit test должен проверить по одному модулю/функции вашего кода. При вызове других модульных тестов он тестирует более одного устройства. Я разбиваю его на отдельные тесты.

Ответ 6

Да - модульные тесты должны быть раздельными и должны быть направлены на проверку только одной вещи (или, по крайней мере, небольшого количества тесно связанных вещей). В стороне, вызовы данных. Проверить и phone.Expect в вашем методе тестирования создают ожидания, а не звонки, которые могут сделать ваши тесты хрупкими, если вы рефакторинг...

Ответ 7

Модуль против модуля.... мы также считаем, что тесты также должны зависеть от методов многократного использования и должны тестироваться на уровне тестирования уровня api. Многие просто тестируют один класс, но многие ошибки связаны с этой интеграцией между уровнем класса. Мы также используем verifydesign, чтобы гарантировать, что api не зависит от реализации. Это позволяет вам реорганизовать весь компонент/модуль, не касаясь теста (и мы это пропустили на самом деле, и он отлично работал). Конечно, любые архитектурные изменения заставляют вас реорганизовывать тесты, но, по крайней мере, дизайнерские изменения в модуле не вызывают работу рефакторинга теста (если вы не измените поведение api, конечно, неявно, как увольнение большего количества событий, чем вы привыкли, будет "изменяться апи" в любом случае).