JUnit проверить сбой базы данных?

Question

Я пытаюсь создать тест, который имитирует сбой системы, чтобы обеспечить целостность базы данных XML Oracle Berkeley DB. В настоящее время происходит потеря данных во время операции вставки, поэтому я хотел бы настроить тест, который начнет вставлять произвольное количество документов и мешать процессу в процессе (сродни тому, кто дергал шнур питания). После того, как процесс умирает, я хочу создать новый процесс и открыть базу данных, чтобы убедиться, что она открывается правильно.

Юнит-тест является одним из многих в сборке maven, и этот тест должен выполняться в средах Linux и Windows XP. Мой текущий мыслительный процесс состоит в том, чтобы разработать сценарий для обеих операционных систем, поскольку я могу использовать сценарий, чтобы завершить процесс и запустить новый вместо него. У меня есть другие варианты? Могу ли я создать отдельное пространство процесса / ВМ, используя JUnit?

Answer 1

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

1. Используйте класс ProcessBuilder для создания и запуска процесса, сохранения возвращенного объекта Process.
2. Начните вставлять записи.
3. В какой-то момент уничтожить () процесс.

Пожалуйста, помните предыдущие комментарии о недетерминированном характере этого теста.

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

Answer 2

Я бы не счел это подходящим для теста UNIT. в модульных тестах вы хотите проверить небольшие фрагменты кода, например, код здравомыслия, возможно с макетом БД. или позвонив только часть вашего кода. То, на что вы ссылаетесь, является более сложным тестом, который, возможно, стоит сделать но не обязательно стоит автоматизировать и запускать повторно как часть ваших юнит-тестов который вы, вероятно, запускаете довольно часто (на сборке или ночью или когда-либо). Добавление такого рода теста также, вероятно, замедлит ваше модульное тестирование и наложит ограничения на среду, в которой может выполняться ваше модульное тестирование. Я предлагаю написать меньшие модульные тесты и протестировать все вместе по отдельности.

Me.

Answer 3

Как насчет использования только нитей, а не всего процесса? Например:

• Вы можете создать фоновый рабочий поток и дать ему несколько нагрузок.
• Затем в потоке основного теста дождитесь случайного числа миллисекунд. Тогда убей нить.
• Тогда, может быть, вы захотите снова подождать, чтобы сохранить сохраненные данные (или нет, в зависимости от того, что вы тестируете)
• Тогда управляй своим здравомыслием. Если он выбрасывает, тест не пройдёт здесь, как вам нужно!
• Вот и все.

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

Answer 4

Этот тип поведения идеально подходит для транзакций. Если бы ваш код запускал транзакцию, база данных знала бы, как обеспечить согласованность данных, когда транзакция прерывается из-за умирающего процесса. Возможно, вы изобретаете колесо здесь. У Daily WTF есть хороший пример того, как мы дурачимся, изобретая колесо .

Внимательно посмотрите на свою первую ревизию и скажите себе: "перчатки".