2010-01-22 4 views
5

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

Единичный тест является одним из многих в конструкции maven, и этот тест должен запускаться в среде linux и Windows XP. Мой текущий процесс состоит в том, чтобы выработать сценарий для обеих операционных систем, поскольку я могу использовать сценарий для уничтожения процесса и создания нового на своем месте. Есть ли у меня другие варианты? Могу ли я создать отдельное пространство процесса/VM с помощью JUnit?

+0

Вы хотите протестировать базу данных? Или вы хотите протестировать свой код, который использует эту базу данных? –

+0

Я хочу, чтобы он тестировал мой код, поскольку данная база данных встроена. Повреждение данных во время сбоя системы - это известная проблема с не-транзакционным DB Berkeley DB (который мы должны использовать). Я выполняю некоторые проверки работоспособности в моем коде оболочки, чтобы смягчить коррупцию. – toddk

+8

Затем вы захотите написать модульные тесты, чтобы доказать, что ваши проверки работоспособности делают то, что они должны делать. Вы можете написать макет интерфейса БД и имитировать различные сбои, чтобы иметь детерминированное поведение. Основная проблема заключается в доказательстве того, что проверенные вами меры безопасности предотвращают описанную вами коррупцию. Я бы не сделал этого в модульном тесте, если ошибки не воспроизводятся при каждом испытании. Если это не так, я бы рассматривал тест как тест на перфективность/стабильность. – ShabbyDoo

ответ

1

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

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

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

Я столкнулся с SQLite team also doing a simulated failure strategy как часть их автоматического набора тестов.

0

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

Посмотрите на свою первую ревизию и скажите себе: «перчатки».

+4

Ты проповедуешь хор. Мне сказали, что мы не можем использовать транзакционную версию БД ... поэтому я думаю, мне нужно спросить «почему бы и нет?». прежде чем идти гораздо дальше. – toddk

0

Как использовать только потоки в целом процесса? Например:

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

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

0

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

Me.

Смежные вопросы