Проверка результатов Factory в unit test

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

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

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

Ответ 1

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

Убедитесь, что объект - это конкретная конкретная реализация, которую вы искали:
```
IMyInterface fromFactory = factory.create(...);  
Assert.assertTrue(fromFactory instanceof MyInterfaceImpl1);
```
Вы можете проверить, установлены ли factory конкретные экземпляры с допустимыми переменными экземпляра.

Ответ 2

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

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

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

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

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

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

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

Заводские испытательные заводы

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

Поскольку фабрики не меняются со временем (потому что тогда они будут "строителями", что является еще одним шаблоном), нет никаких команд для тестирования.

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

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

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

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

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

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

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

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

Ответ 3

if (myNewObject instanceof CorrectClass)
{
    /* pass test */
}

обновление:

Не знаю, почему это произошло, поэтому я немного расширю его...

public void doTest()
{
    MyInterface inst = MyFactory.createAppropriateObject();
    if (! inst instanceof ExpectedConcreteClass)
    {
        /* FAIL */
    }
}

Ответ 4

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

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

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