Тест JUnit отказ базы данных?

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

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

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

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

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

Попросите усердно взглянуть на вашу первую ревизию и сказать себе, «Перчатки».

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

В принципе, я соглашусь, что групповой стандарт - это хорошо. На практике мой опыт заключается в том, что им трудно согласиться - например, один человек будет религиозен в открытии родителей в конце линии, в то время как другой будет так же религиозен в том, чтобы иметь их на линии самостоятельно. Их также трудно обеспечить, особенно если нет обзоров кода или другого механизма для обеспечения соответствия кода стандарту. Я бы сказал, стремиться к тому, что работает лучше всего; Например, в моем предыдущем примере любой метод кажется разумно читаемым, так что, возможно, пусть этот слайд, но если вы используете соглашение об именовании переменных, не позволяйте ему скользить, когда кто-то пытается использовать «a» для переменной, содержащей имя клиента!

Я думаю, что лучший компромисс, который вы получите в этом случае (и это обсуждаемая тема, конечно), это создать что-то по линии класса ClubStartCoach , который предоставляет свойства ClubManager и Coach .

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

Я.

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

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

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