Как к конструкции фиктивного объекта?

Настройка уровня совместимости базы данных на 110 сработала для меня.

Чтобы проверить уровень совместимости, запустите этот скрипт:

select compatibility_level from sys.databases where name = '<YOUR_DB_NAME>'

Чтобы установить уровень совместимости, используйте этот скрипт:

alter database <YOUR_DB_NAME> set compatibility_level = 110
6
задан Betlista 16 April 2013 в 08:59
поделиться

6 ответов

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

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

6
ответ дан 10 December 2019 в 00:47
поделиться

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

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

4
ответ дан 10 December 2019 в 00:47
поделиться

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

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

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;
    }
}

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

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

Я теперь имею хорошо решение непосредственной проблемы, Спасибо!

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

1
ответ дан 10 December 2019 в 00:47
поделиться

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

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

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

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

0
ответ дан 10 December 2019 в 00:47
поделиться

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

Если бы не, то Вы ceartanly извлекли бы выгоду из приобретения знаний о том понятии. Я предполагаю старую добрую Инверсию Контейнеров Управления, и шаблон Внедрения зависимости Martin Fowler будет служить хорошим введением.

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

0
ответ дан 10 December 2019 в 00:47
поделиться

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

Что-то, кажется, находится неправильно в Вашем подходе к тестированию здесь. Какую-либо причину, почему необходимо протестировать это явные конструкторы, называют?
Утверждение типа возвращенного объекта кажется хорошо для тестирования реализаций фабрики. Рассматривайте createObject как черный ящик.. исследуйте то, что это возвращает, но не микросправляйтесь, как это делает это. Никому не нравится это :)

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

  • Любой пытается израсходовать некоторое усилие на получение тех противных входных объектов, 'instantiable' под тестовой обвязкой. Пойдите Вверх дном в Вашем подходе.
  • Если это неосуществимо, вручную проверьте его с точками останова (я знаю, что это сосет). Затем засуньте "Касание это на Ваш собственный риск" комментарий в видимой зоне в исходном файле и продвиньтесь вперед. Боритесь с другим днем.
-1
ответ дан 10 December 2019 в 00:47
поделиться
Другие вопросы по тегам:

Похожие вопросы: