Как имитировать строительство объекта?

Question

Есть ли способ имитировать построение объекта с помощью JMock в Java?

Например, если у меня есть метод как таковой:

public Object createObject(String objectType) {
    if(objectType.equals("Integer") {
        return new Integer();
    } else if (objectType.equals("String") {
        return new String();
    }
}

... есть ли способ смоделировать ожидание построения объекта в методе тестирования?

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

Так что вместо:

assertTrue(a.createObject() instanceof Integer);

У меня могло бы быть ожидание вызова определенного конструктора.Просто чтобы сделать его немного чище и выразить то, что на самом деле тестируется, более читаемым способом.

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

---

Для получения дополнительной информации:

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

Возможно, ближе к тому, что я на самом деле ищу, это:есть ли способ издеваться над целым классом (используя CGLib) одним махом, не указывая каждый метод для заглушки?

Итак, макет оборачивается в конструктор, поэтому, очевидно, в нем могут вызываться методы, способен ли JMock динамически издеваться над каждым методом?

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

Answer 1

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

Но с точки зрения издевательства над вызовом конструктора - нет.Фиктивные объекты предполагают существование объекта, тогда как конструктор предполагает, что объект не существует.По крайней мере, в java, где выделение и инициализация происходят вместе.

Answer 2

jmockit может это сделать.

Смотрите мой ответ в https://stackoverflow.com/questions/22697#93675

Answer 3

Увы, я думаю, что виноват в том, что задал неправильный вопрос.

Простая фабрика, которую я пытался протестировать, выглядела примерно так:

public Wrapper wrapObject(Object toWrap) {
    if(toWrap instanceof ClassA) {
        return new Wrapper((ClassA) toWrap);
    } else if (toWrap instanceof ClassB) {
        return new Wrapper((ClassB) toWrap);
    } // etc

    else {
        return null;
    }
}

Я задавал вопрос, как определить, был ли вызван "new ClassAWrapper( )", потому что объект toWrap было трудно получить в изолированном тесте.И оболочка (если ее вообще можно так назвать) довольно странная, поскольку она использует один и тот же класс для обертывания разных объектов, просто использует разные конструкторы [1].Я подозреваю, что если бы я задал этот вопрос немного лучше, то быстро получил бы ответ:

"Вы должны создать макет объекта toWrap, чтобы он соответствовал экземплярам, которые вы тестируете в разных методах тестирования, и проверить полученный объект-оболочку, чтобы найти возвращаемый правильный тип...и надеюсь, вам повезет настолько, что вам не придется издеваться над миром, чтобы создавать разные экземпляры ;-) "

Теперь у меня есть подходящее решение насущной проблемы, спасибо!

[1] открытие вопроса о том, следует ли это реорганизовывать, выходит далеко за рамки моей текущей проблемы :-)

Answer 4

Знакомы ли вы с Внедрение зависимостей?

Если нет, то вам определенно было бы полезно узнать об этой концепции.Я думаю, что старый добрый Инверсия управляющих контейнеров и шаблон внедрения зависимостей авторство Мартина Фаулера послужит хорошим введением.

С внедрением зависимостей (DI) у вас будет объект-контейнер DI, который способен создавать для вас все виды классов.Затем ваш объект будет использовать контейнер DI для создания экземпляров классов, и вы будете издеваться над контейнером DI, чтобы проверить, что класс создает экземпляры ожидаемых классов.

Answer 5

Внедрение зависимости или Инверсия управления.

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

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

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

Answer 6

Я надеюсь, что такового нет.Предполагается, что Mocks имитируют интерфейсы, у которых нет конструкторов...просто методы.

Кажется, что-то не так в вашем подходе к тестированию здесь.Есть какая - нибудь причина, по которой вам нужно проверить, что вызываются явные конструкторы?
Утверждение типа возвращаемого объекта кажется приемлемым для тестирования заводских реализаций.Обрабатывайте CreateObject как черный ящик..изучите, что он возвращает, но не контролируйте на микроуровне, как он это делает.Это никому не нравится :)

Обновление по обновлению: Ой!Отчаянные меры для отчаянных времен, да?Я был бы удивлен, если JMock допустит это...как я уже сказал, это работает на интерфейсах..не конкретные типы.Итак

• Либо попробуйте и потратьте некоторые усилия на то, чтобы сделать эти надоедливые входные объекты "инстанцируемыми" в тестовом режиме.Идите снизу вверх в своем подходе.
• Если это неосуществимо, вручную протестируйте это с помощью точек останова (я знаю, что это отстой).Затем прикрепите комментарий "Трогайте это на свой страх и риск" в видимой зоне исходного файла и двигайтесь дальше.Сразись в другой раз.