java - уроки - tdd тестирование




Проверка результатов Factory в единичном тесте (3)

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

Я хотел бы знать ответ на Java, но если есть решение, которое пересекает языки, я хотел бы это знать.

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


Поскольку я не знаю, как выглядит ваш заводский метод, все, что я могу посоветовать сейчас, это

  1. Убедитесь, что объект - это конкретная конкретная реализация, которую вы искали:

    IMyInterface fromFactory = factory.create(...);  
    Assert.assertTrue(fromFactory instanceof MyInterfaceImpl1);
  2. Вы можете проверить, если заводская настройка конкретных экземпляров с действительными переменными экземпляра.


@ cem-catikkas Я думаю, было бы правильнее сравнивать значения getClass (). getName (). В случае, если класс MyInterfaceImpl1 является подклассом, ваш тест может быть нарушен, так как подкласс является экземпляром MyInterfaceImpl1. Я бы переписал следующим образом:

IMyInterface fromFactory = factory.create(...);  
Assert.assertEquals(fromFactory.getClass().getName(), MyInterfaceImpl1.class.getName());

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


То, что вы пытаетесь сделать, это не Unit Testing

Если вы проверяете, являются ли возвращенные объекты экземплярами конкретных конкретных классов, вы не являетесь модульным тестированием. Вы являетесь интеграционным тестированием. Хотя интеграционное тестирование важно, это не одно и то же.

При модульном тестировании вам нужно только проверить сам объект. Если вы заявляете о конкретном типе возвращаемых абстрактных объектов, вы проверяете реализацию возвращаемого объекта.

Единичное тестирование объектов в целом

При модульном тестировании есть четыре вещи, которые вы хотите утверждать:

  1. Возвращаемые значения запросов (непустые методы) - это то, что вы ожидаете от них.
  2. Побочные эффекты команд (void methods) изменяют сам объект, как вы ожидаете.
  3. Получены команды, отправляемые на другие объекты (обычно это делается с помощью mocks).

Кроме того, вы хотите только проверить, что можно было наблюдать из экземпляра объекта, то есть в публичном интерфейсе. В противном случае вы привязываетесь к определенному набору деталей реализации. Это потребует, чтобы вы изменили свои тесты, когда эти детали изменились.

Единичные испытательные заводы

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

Поскольку Фабрики не меняются со временем (потому что тогда они будут «Строителями», что является другим образцом), нет никаких команд для тестирования.

Фабрики отвечают за создание объектов, поэтому они не должны зависеть от других заводов, чтобы сделать это для них. Они могут зависеть от Builder, но даже в этом случае мы не должны проверять правильность Builder, только если Builder получает сообщение.

Это означает, что все, что вам нужно проверить на Фабриках, это то, посылают ли они сообщения объектам, от которых они зависят. Если вы используете Dependency Injection, это почти тривиально. Просто издевайтесь над зависимостями в модульных тестах и ​​убедитесь, что они получают сообщения.

Сводная информация об организационных единицах

  1. Не проверяйте поведение и детали реализации возвращаемых объектов! Ваша фабрика не несет ответственности за реализацию экземпляров объекта!
  2. Проверьте, получены ли команды, отправленные в зависимости.

Вот и все. Если нет зависимостей, тестировать нечего. Кроме того, может быть, утверждать, что возвращаемый объект не является null ссылкой.

Интеграционные испытательные заводы

Если у вас есть требование, чтобы возвращаемый тип абстрактного объекта был экземпляром конкретного конкретного типа, это относится к тестированию интеграции.

Другие здесь уже ответили, как это сделать, используя оператор instanceof .





tdd