Блог

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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