Могу ли я создать тест блокировки базы данных в Nunit?

Question

В этом asp.net я очищаю, возможно возникновение взаимоблокировок. Я хочу убедиться, что код обрабатывает их правильно, поэтому я пытаюсь написать тесты NUnit, которые вызывают тупик .....

DAO делится на объекты. Каждая сущность имеет набор тестов, которые окружены методами Startup () и Teardown (), которые создают область транзакций и затем откатывают ее после завершения тестов. Это прекрасно работает для всего остального, но совершенно бесполезно для тупиков.

Как я могу настроить и запустить «тупиковый» тест с использованием TransactionScope и SQL2000 (т. Е. Задействован MSDTC), который можно надежно воспроизвести? Более подробно: я знаю, что есть ситуация, когда два пользователя вызывают две функции с разными, специфическими значениями данных, и в результате тупик может . Как я могу смоделировать это в NUNIT - и заставить тупик всегда случиться?

И да, я начал с плана действий «Почему бы вам не остановить взаимоблокировки, возникающие в первую очередь», но я не контролирую код, где могут возникать взаимоблокировки - я просто вызываю функции они могут зайти в тупик.

Answer 1

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

Основная идея заключается в том, что вы указываете своей инфраструктуре Mock Object (мне нравится TypeMock ) вместо этого генерировать исключение, что-то вроде этого:

MockObject mo = MockManager.MockObject(typeof(MyDeadlockException));
mock.ExpectAndThrow("MyMethod", (MyDeadlockException)mo.Object); 

Идея в основном такая же для других фальшивых фреймворков.

Answer 2

Большинство из этих решений включают в себя несколько потоков. Вот тот, который не делает.

Закройте эти лазейки - Воспроизведите ошибки базы данных

Автор Алексей Кузнецов.

Answer 3

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

Макет - это идеальный способ имитировать это, если вы вызываете сервис, и он возвращает ошибку. Просто сделайте, чтобы макет вернул ожидаемую вами ошибку. Если вы ждете тайм-аут или что-то еще, то применяется то же самое.

Как правило, модульное тестирование должно выполняться только на тестируемом коде и не полагаться на какой-либо другой код или компоненты. Тем не менее, базы данных - это, по сути, еще один компонент, и вы, вероятно, проводите какие-то функциональные тесты, используя nunit для их управления.

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

Answer 4

Подойдя к этому слепому, но возможно ли в вашем методе TestSetup создать SQLConnection для вашей базы данных? Затем, используя это, вы можете просто выполнить команду для блокировки таблицы или выполнить какое-либо действие для блокировки записи или страницы? Таким образом, это было бы за пределами любых других транзакций, которые у вас есть? Похоже, что это будет вариант, который вы уже рассмотрели, хотя. Что мне не хватает в вашей ситуации?

Answer 5

Что если вы вручную заблокировали стол и ВСЕГДА оставили его заблокированным? Тогда любое действие, которое вы предприняли против этой таблицы, привело бы к тупиковой ситуации?

Answer 6

Что если один из ваших тестов в середине вашей транзакции просто "подождет" примерно 5 минут? Или вы просто пишете тест, который запускает транзакцию, создает новую запись, а затем обновляет эту запись без фиксации. Затем запустите новую транзакцию и попробуйте прочитать ту запись, которая была создана и в настоящее время обновляется. Вы зашли в тупик.