TDD - проверка наличия интерфейса

Question

Начинаем работать с TDD, и я хочу основать модель на основе репозитория. Тем не менее, как я могу использовать NUnit, чтобы эффективно сказать:

SomeInterfaceExists()

Я хочу создать тесты для каждой модели домена (например, ICarRepository, IDriverRepository) и т. Д.)

Имеет ли это смысл?

Привет

Answer 1

TDD означает, что вы управляете своей разработкой (дизайном), проводя тестирование в первую очередь, то есть вы

1. Напишите план (методы) вашего класса, который вы хотите протестировать
2. Вы создаете юнит-тест для эскиза вашего класса
3. Вы запускаете свой юнит-тест -> он не пройдёт
4. Вы взломали свой класс, достаточно, чтобы пройти тест
5. Вы реорганизуете свой класс

Это повторяется для каждого элемента.

Answer 2

Это не то, что вы тестируете с помощью TDD. Тест в том, могу ли я вызвать один из методов этого интерфейса в этом классе и возвращает ли он правильные вещи.

Answer 3

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

Answer 4

Наличие интерфейсов implicity проверяется каждый раз, когда вы используете интерфейс в тесте. Например, до того, как интерфейс или какие-либо его реализации существуют, вы можете написать тест, который говорит, в частности:

ICar car = new Convertible();

Это устанавливает существование интерфейса ICar - ваш тест не будет компилироваться, пока не будет создан - и этот Convertible реализует ICar. Каждый метод на автомобиле, который вы вызываете, будет разрабатывать больше интерфейса.

Answer 5

Вы можете написать что-то вроде следующего:

void AssertSomeInterfaceExists(object domainObject)
{
    Assert.IsTrue(domainObject is ICarRepository);
}

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

Answer 6

Вам не нужно проверять, существует ли ваш интерфейс или нет. Вы на самом деле ничего не "тестируете" там.

Answer 7

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

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

Answer 8

Что произойдет, если ваш объект домена не требует кода доступа к данным. Пример - корзина для покупок?