Может ли каркас Mock сделать это для меня?

Question

Я немного запутался

из вики: «Это означает, что истинный издеваться ... выполнения тестов на данных, передаваемых в метод требует в качестве аргументов.»

Я никогда не использовал модульное тестирование или макет. Я думал, что модульные тесты предназначены для автоматических тестов, для чего нужны тесты?

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

Когда я выполняю свою программу с помощью mocks, могу ли я легко заменить их на POCO позже, чтобы создать сущность, например, работать довольно быстро?

Редактировать: Я не хочу использовать модульное тестирование, но использование Mocks в качестве полной замены для сущностей + базы данных было бы неплохо.

Answer 1

Да, я думаю, вы немного смущены.

Макетные рамки предназначены для создания объектов «Mock», которые в основном подделывают часть функциональности ваших реальных объектов, поэтому вы можете передавать их методам во время тестов, не прибегая к необходимости создания реального объекта для тестирования.

Позволяет запускать через быстрый пример

у вас есть «() Сохранить» метод, который принимает «Док» объект и возвращает успех флаг «булевой»

public bool Save(Doc docToSave(){...} 

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

Вместо этого можно использовать фреймворк Mocking для создания объекта «Doc» для вас.

Синтаксис различного между рамками, но и в псевдо-коде можно было бы написать что-то вроде этого:

CreateMock of type Doc 
SetReturnValue for method Doc.data = "some test data" 

Рамки насмешливой создаст фиктивный фиктивный объект типа Doc, который правильно возвращает «тестовые данные», когда это Вызывается свойство .data '.

Вы можете использовать этот фиктивный объект, чтобы проверить свой метод сохранения:

public void MyTest() 
{ 
    ... 
    bool isSuccess = someClass.Save(dummyDoc); 
    ... 
} 

Рамки насмешливый гарантирует, что, когда ваш «Save()» метод обращается свойства на объекте dummyDoc, правильно данные возвращаются , и спасение может произойти естественным образом.

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

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

Если вы хотите что-то, что заменит ваши классы баз данных, чтобы позже вы могли передумать, вам нужно написать интерфейсы или абстрактные классы, чтобы предоставить методы, которые вам нужны, чтобы соответствовать семантике сохранения/загрузки, тогда вы можете заполните несколько полных реализаций в зависимости от того, какие типы хранилищ вы выберете.

Answer 2

I думаю что вы ищете Repository Pattern. Эта ссылка предназначена для NHibernate, но общая модель должна работать и для Entity Framework. В поисках этого я нашел Implementing Repository Pattern With Entity Framework.

Это абстрагирует детали фактического O/RM за интерфейсом (или набором интерфейсов).

(я не эксперт по хранилищам, так пожалуйста, напишите лучше разъяснение/ссылку, если кто имеет их.)

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

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