Модульные тесты .NET для чтения / сохранения данных в базе данных

Question

Большинство вещей, которые я читал о модульных тестах, касается тестирования ваших классов и их поведения. Но как вы тестируете сохранение данных в базу данных и чтение данных из базы данных. В нашем проекте сохранение и чтение данных осуществляется через сервисы, которые используются Flex-приложением (используя WebORB в качестве шлюза). Например, сервис читает всех пользователей, которые имеют доступ к определенному модулю. Как вы проверяете, что возвращаемые пользователи фактически являются пользователями, имеющими доступ к этому модулю?

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

То же самое относится и к хранимым процедурам. Как вы тестируете sp, если в базе данных нет данных? Реальность такова, что для тестирования определенных хранимых процедур нам нужны данные в десяти таблицах ...

thx, Ливен Кардоен

Answer 1

это скорее интеграционный тест, чем модульный тест.

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

Самая большая проблема здесь заключается в том, что если у вашего клиента произошел сбой - вы не можете запускать такие тесты ... Другая проблема заключается в том, что данные в вашей test-db будут сбрасываться при каждом запуске таких тестов.

Answer 2

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

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

Answer 3

Вы можете иметь тесты для действий с БД, но, по возможности, старайтесь избегать этого, в противном случае:

• Они будут работать медленнее, чем обычные тесты (скорее всего, это интеграционные тесты)
• Они требуют больше работы по настройке / разборке (дБ / схема / данные таблицы)
• Они вводят внешнюю зависимость от вашей тестовой среды

Это может также быть запахом кода, что ваши классы не отделяют работу, связанную с БД, от другой работы, например, бизнес логика. Однако, возможно, нет, у нас есть каркасный тест, который проверяет, что автоматически сгенерированный сценарий SQL возвращает ожидаемое увеличенное значение идентификатора после вставки новых данных. У AFAIK нет способа проверить, что этот код работает, кроме как выполнить его для БД. Вы можете сделать это или просто предположить, что если SQL совпадает с тем, что вы ожидаете, то это нормально, но мне не нравится это предположение, поскольку на него опирается так много другого кода.

В зависимости от вашей тестовой среды вы должны пометить эти тесты как связанные с [База данных], что позволит вам отделить их от других тестов.

Answer 4

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

Answer 5

Попробуйте использовать mbunit . Это среда тестирования .NET, которая позволяет заполнить базу данных в настройках, а затем откатить изменения, внесенные в базу данных во время тестов, восстановив базу данных до ее прежнего состояния. Здесь есть быстрая запись здесь .

Answer 6

Забавно, у меня та же проблема с моим проектом. Насмешка, наверное, хороший путь, но я этого не пробовал. Как правило, мы заполняем наши таблицы данными. Я пишу модульные тесты, которые используют возможности CRUDL данного класса. Поэтому, если у меня есть класс Person, модульные тесты включают создание, чтение, обновление, удаление и составление списка. Эти методы имеют тенденцию вызывать хранимые процедуры (в большинстве случаев), поэтому он также проверяет и эту часть.

Существуют инструменты, которые могут сбрасывать данные испытаний.

Генератор данных Sql от Red Gate

Дайте нам знать, какой подход сработал для вас.

Answer 7

• A: Если вы используете FlexApplication для прямого доступа к вашей базе данных, это будет нелегко проверить. Между вами должен быть тестируемый интерфейс / слой.
• B: Помещение данных в базу данных является обычным делом в «TestSetup-Phase».
• C: Должна быть возможность протестировать интерфейс, который фактически запускает хранимую процедуру.
  • если это sprocs, который не используется графическим интерфейсом, а только sql-to-sql, то это также системы, которые тестируют sprocs. обычно у вас есть sproset sp_setup и sp_teardown до и после реальных тестов