Я должен вынудить исключения протестировать их?

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

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

Может быть, более сложный случай потребует этого.

В качестве дополнительной заметки, не могли бы вы выполнить откат при любом типе исключения?

В ядре Linux 80% ошибок в драйверах связаны с кодом обработки ошибок.

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

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

Я надеюсь, что транзакция будет откатной, если Displose () вызывается до Commit (), поэтому вам вообще нужен улов ?

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

Судя по названию исключения (HibernateException), я думаю, что это не исключительный случай. Так может случиться при нормальной работе. Если это так, я бы сделал тест, который вызывает исключение, чтобы убедиться, что оно обрабатывается правильно.

Вот мои правила для идеального тестирования поведения при сбоях:

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

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

Прежде чем рассматривать комплект модульных тестов как завершенный, нужно взглянуть на кодовое покрытие тестируемого кода. Для нетривиального кода почти всегда есть один способ, которым моя ветвь кода не покрывает мои модульные тесты или, что еще хуже, ведет себя не так, как я предполагал. На удивление часто решение состоит в том, чтобы удалить этот код, а не добавлять дополнительные тесты. Я не говорю, что нужно достичь 100% покрытия, но нужно проводить модульное тестирование, основанное на покрытии кода, потому что это более наглядный способ понять и выявить поведение кода, которое существует. Простой взгляд на него может дать вам новые идеи о том, как рефакторинг кода для достижения принципа единой ответственности и разделения проблем .

Для нетривиального кода почти всегда есть один способ, которым моя ветвь кода не покрывает мои модульные тесты или, что еще хуже, ведет себя не так, как я предполагал. На удивление часто решение состоит в том, чтобы удалить этот код, а не добавлять дополнительные тесты. Я не говорю, что нужно достичь 100% покрытия, но нужно проводить модульное тестирование, основанное на покрытии кода, потому что это более наглядный способ понять и выявить поведение кода, которое существует. Простой взгляд на него может дать вам новые идеи о том, как рефакторинг кода для достижения принципа единой ответственности и разделения проблем .

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

решение состоит в том, чтобы удалить этот код, а не добавлять дополнительные тесты. Я не говорю, что нужно достичь 100% покрытия, но нужно проводить модульное тестирование, основанное на покрытии кода, потому что это более наглядный способ понять и выявить поведение кода, которое существует. Простой взгляд на него может дать вам новые идеи о том, как рефакторинг кода для достижения принципа единой ответственности и разделения проблем .

решение состоит в том, чтобы удалить этот код, а не добавлять дополнительные тесты. Я не говорю, что нужно достичь 100% покрытия, но нужно проводить модульное тестирование, основанное на покрытии кода, потому что это более наглядный способ понять и выявить поведение кода, которое существует. Простой взгляд на него может дать вам новые идеи о том, как рефакторинг кода для достижения принципа единой ответственности и разделения проблем .

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

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

Я очень надеюсь, что вы отдельно протестируете transaction.Rollback () с тестами, которые исчерпывают все возможные ситуации, которые вы можете придумать. Однако при условии, что тестирование было исчерпывающим, я, вероятно, не стал бы вызывать исключение, поскольку в обработчике больше ничего нет.