Как я должен издеваться над подключением к данным

Question

Я пытаюсь провести модульное тестирование моего уровня доступа к данным, и я пытаюсь смоделировать мою связь с данными для модульного тестирования моего DAL, и я отрываюсь от попыток создать команды. Я думал об использовании очереди IDbParameters для создания параметров, но модульные тесты затем требуют, чтобы параметры были настроены в правильном порядке. Я использую MOQ и, посмотрев вокруг, чтобы найти какую-то документацию, я нашел много рекомендаций не делать этого, а написать оболочку для соединения, но я утверждаю, что мой DAL должен быть обертка для моей базы данных, и я не думаю, что должен писать обертки ... если я это сделаю, как мне выполнить модульное тестирование подключения к базе данных для моей обертки? Написав другую обертку? Кажется, что это черепахи внизу.

Так есть ли у кого-нибудь какие-либо рекомендации или учебные пособия, касающиеся этой конкретной области модульного тестирования / издевательства?

Answer 1

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

Answer 2

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

Я перешел на .NET, и здесь используется обертка вокруг System.Data & Oracle.DataAccessи если честно, мне нравится такой подход.

Оболочка просто предоставляет интерфейс IDatabase с набором методов, таких как DataTable ExecuteFunction(...), которые предлагают простой способ вызова функции или процедуры оракула.Единственный класс из System.Data, видимый клиентами этого API, - это DataTable.Оболочка обрабатывает все беспорядок с IDbParameter.Оболочка имеет только интеграционные тесты.

Модульное тестирование фактического DAL очень просто, плюс написание DAL делает это немного лучше.Менее ужасный шаблон для решения.

утверждение, что мой DAL должен быть оболочкой для моей базы данных

DAL обеспечивает доступ к бизнес-функциям, хранящимся в базе данных.Оболочка БД удаляет код котельной пластины (и позволяет вам его высмеивать).

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

Не надо.Примите, что некоторые вещи являются интеграционными тестами.

Answer 3

Moq использует наследование для создания ложного класса. Недостатком этого подхода является то, что класс, который вы пытаетесь подделать, должен передаваться как интерфейс, по крайней мере, не будет запечатанным классом.Одно из решений состоит в том, чтобы создать класс-оболочку вокруг «немодного» класса и вместо этого смоделировать этот класс, к сожалению, это решение требует значительного обслуживания.

Если вы готовы заплатить за фальшивый фреймворк, который позволил бы имитировать запечатанные классы, подумайте о покупке Typemock Isolator или JustMock - оба могут подделать практически любойКласс и метод .NET (включая закрытые классы и статические методы).