Тестирование интерфейса имеет смысл?

Question

Я новичок в TDD, но я не уверен, зачем мне тестировать интерфейс?

Имеет ли смысл приведенный ниже код ??

public interface IInterface
{
    int Value { get; }
}


[TestMethod]
public void Test_iinterface_value()
{
    var iinterface = mockery.NewMock<IInterface>();
    Expect.Once.On(iinterface).GetProperty("Value").Will(Return.Value(10));
    Assert.AreEqual(iinterface.Value, 10, "Doh!");
}

Answer 1

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

Answer 2

Это известно как анти-шаблон Mockery TDD .

. Однако вы можете написать набор тестов, применимый ко всем реализациям данного интерфейса, чтобы гарантировать, чтоконтракты должным образом выполняются.Например, это то, что Grensesnitt делает.

Answer 3

Тестирование интерфейсов не имеет смысла. Тестирование фиктивного объекта также не имеет смысла - если только вы не используете фиктивный объект для проверки реализованного метода абстрактного класса (abstract в определении c #).

Answer 4

Идея создания макета для интерфейса заключается в том, чтобы протестировать другой объект («тестируемый объект»), для которого требуется, чтобы этот макет был создан или правильно инициализирован.Создание макета только для тестирования самого макета ИМХО, похоже, упускает смысл модульного тестирования.

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

Answer 5

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

В большинстве случаев пользовательский интерфейс состоит из стандартных классов, предоставляемых фреймворком, с небольшими изменениями, поэтому, если вы не сомневаетесь в возможностях вашей пользовательской среды или не разрабатываете ее самостоятельно, нет реальной необходимости в модульных тестах на UI классы.

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