Модульное тестирование, веб-сервисы и транзакции с базами данных - PullRequest
1 голос
/ 02 сентября 2010

Я пытаюсь написать контрольные примеры для своих веб-служб таким образом, чтобы я мог откатить любые изменения в базе данных, которые они могут внести. Я могу попытаться окружить их областью транзакции, но как мне указать контекст для транзакции? Другими словами, как транзакция узнает, на какой базе данных и на каком сервере выполнить откат? В моем случае SQL-сервер работает как локально, так и веб-сервисами. Прежде чем вы скажете мне вызывать веб-сервисы напрямую без клиента, пожалуйста, поймите, что у веб-сервисов есть очень специфические настройки среды выполнения, которые было бы непросто воспроизвести для моих тестовых случаев. Возможно, объем транзакции не то, что я хочу использовать, есть ли альтернатива? Есть ли функция базы данных, которую я мог бы вызвать, чтобы начать транзакцию? Спасибо.

1 Ответ

2 голосов
/ 02 сентября 2010

Сначала вы не проводите модульное тестирование. Модульное тестирование - это тестирование одного небольшого блока кода (функции). Когда вы тестируете функцию, вы создаете модульный тест для каждого пути выполнения, чтобы у вас был полный охват тестируемого кода. Но ваша тестируемая система включает в себя связь между клиентом и сервисом и связь с базой данных = несколько уровней кода + конфигурация. Это называется интеграционным тестированием.

Проблема в том, как вы разработали свой сервис? Ваш сервис обслуживает транзакции? Поток транзакций позволяет запустить транзакцию на вашем клиенте и передать ее службе (распределенная транзакция). Это не поведение по умолчанию, и оно требует специальной настройки привязок WCF. Если вы используете этот подход, вы можете сделать то же самое в своем тесте. Запустите транзакцию при тестировании и откатите транзакцию в конце теста. Если вы не спроектировали сервис для потоковой транзакции, вы просто не сможете его использовать, потому что ваша транзакция, запущенная в тесте, не повлияет на сервис. В этом случае у вас есть несколько вариантов:

  • Создать ручную компенсацию. В конце каждого теста запускайте пользовательский SQL, чтобы переместить данные в исходное состояние. Это имитирует откат. Я не рекомендую такой подход.
  • Повторное создание базы данных в начале каждого теста. Это медленно, но полностью приемлемо, потому что интеграционные тесты обычно запускаются только на сервере сборки несколько раз в день.
  • Не проверять уровень сервиса WCF. Служба WCF должна быть лишь оболочкой бизнес-логики или логики доступа к данным. Так что не проверяйте уровень обслуживания, а вместо этого проверяйте завернутый слой. Вы, вероятно, можете использовать транзакции там. Этот подход хорошо сочетается с предыдущим, так что у вас есть небольшой набор сложных интеграционных тестов, для которых требуется воссоздание базы данных, и больший набор тестов, которые могут выполнять откат и использовать ту же базу данных.
...