Каков правильный способ модульных тестовых зон вокруг исключений

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

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

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

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

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

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

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