Что является правильным способом для юнит-тестирования областей вокруг исключений

Question

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

Так есть ли единственный способ издеваться над объектами, чтобы исключение могло быть выдано? Это кажется немного бессмысленным. Возможно, лучше просто принять не получая 100% покрытия кода?

Спасибо, Dan

Answer 1

Обычно при работе с низкоуровневыми исключениями, такими как IOException или SQLException в Java, я заключаю их в исключение, расширяющее RuntimeException. Я чувствую, что тестирование этого поведения очень важно, потому что в противном случае есть очень неприятная возможность случайно проглотить исключение.

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

Редактировать: Добавлен пример.

public void store(User user) {
    try {
        userDao.store(user);
    } catch (IOException e) {
        // Logging, perhaps some logic.
        throw new ServiceException(e);
    }
}

@Test(expected = ServiceException.class)
public void Store_Fail() {
    UserDao userDaoMock = createMock(UserDao.class);
    User user = // Create test user.
    userDaoMock.store(user);
    replay(userDaoMock);
    userService.store(user);
    verify(userDaoMock);
}

Здесь тестировать особо нечего, но если по логике необходимо сгенерировать исключение ServiceException, почему бы не протестировать его?

Answer 2

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

Answer 3

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

Я полагаю, что это будет самый простой способ, но вы могли бы также сделать заглушку (иначе говоря, объект, который расширяет реальный объект и заставляет поведение подобно выбрасыванию исключения каждый раз). Или вы можете использовать AOP, но я думаю, что использование библиотеки типа easymock или jmock будет самым простым способом.

Это кажется немного бессмысленным. Возможно, лучше просто принять не получая 100% покрытия кода?

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

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

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