Mocking ISession.Query <T>() для тестирования потребителя

Question

Я пытаюсь избегать использования базы данных в памяти для тестирования (хотя мне, возможно, придется сделать это, если следующее невозможно).Я использую NHibernate 3.0 с LINQ.Я хотел бы иметь возможность смоделировать session.Query<T>() для возврата некоторых фиктивных значений, но я не могу, так как это метод расширения, и их практически невозможно проверить.использование базы данных в памяти) для тестирования запросов сеанса с LINQ?

Answer 1

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

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

Answer 2

Похоже, вы собираетесь усложнять вещи.Я постараюсь сэкономить ваше время =)

Прежде всего давайте начнем с того, что для типичного проекта есть два способа тестирования (я уверен, что вы это знаете, но лучше упомянуть). Интеграционные тесты и Модульные тесты .И обычно (я предполагаю, что у вас есть типичное приложение, чтобы не добавлять «типично» к каждому предложению), вам нужны оба.

Интеграционные тесты выполняются в реальной базе данных, а некоторые из них - в In-Память 1 для лучшей производительности тестирования.

Таким образом, вы, вероятно, имеете в своем приложении mappings и хотите их протестировать, лучше делать интеграционные тесты на реальных БД, и если вы используетеСвободный Nhibernate (если вы этого не сделаете, лучше начать его использовать), это будет кусок пирога .

Тогда у вас, вероятно, есть своего рода хранилище или другой слой доступа к данным (где вы используете Linq), который вы хотите проверить тоже.И вы, вероятно, хотите иметь такие тесты, как:

Когда я отправляю запрос get-customer-by-name , мой компонент доступа к данным должен возвращать customer с указанным именем.

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

Но если у вас много сложных запросов, то я бы согласился с José F. Romaniello, что лучше использовать Enhanced Query Object и тестировать его отдельно.

Вы можете обратить внимание на Среду Sharp Arhitecture , которая нацелена на множество проблем при использовании Nhibernate и тестировании персистентного слоя.

Answer 3

Лучшим подходом будет высмеивать концепцию того, что вы пытаетесь сделать, а не внутренний API внешней системы.Например,

• Запишите запрос в отдельном артефакте, например, IQuerySomething / QuerySomething
• Проверьте свой запрос к базе данных.Попробуйте эту базу данных быть prety, как настоящий db.
• При тестировании чего-то, что зависит от IQuerySomething, макет IQuerySomething.

Фабио Мауло написал об этом шаблоне как EQO (Enhanced Query Object)Я рекомендую вам его пост.

Именно так мы используем в .net практически все.