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

#java #junit #mockito

Вопрос:

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

Метод:

 Class Validator() {

    protected Validator(blah,blah) {

    }

    protected boolean doStuff(String a, String b) {

        try {
          isValidInput(a){
        } catch (Exception e) {
            b = "unknown error"
        }
    }

тестовый пример:

 @Test
public void testException() {

Validator testValidator = new testValidator(blah, blah);

        Validator spy = spy(testValidator);
        String var2 = "unknown error"
        doReturn(new Exception()).when(spy.doStuff(var1, var2));

        assertEquals("unknown error", var2);
}

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

1. Это все равно не сработает, потому что var2 в вашем тесте не будет отражено значение, установленное вами в тестируемом методе.

2. что, если я переведу var2 в «неизвестную ошибку»?

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

4. если есть исключение, оно возвращает false . В блоке исключений я записываю некоторые данные в строковый объект, который передается в качестве входного аргумента в isValidInput(). Если я отключу isValidInput, я не смогу получить доступ к данным, записанным в объект string, который мне нужен. Я также понимаю, что я предоставил ограниченную информацию. здесь и предоставление более широкой картины действительно помогло бы. Спасибо за комментарии, Дэйв

5. Пока вы понимаете, что вы не можете записать строку входного параметра и увидеть ее вне метода.

Ответ №1:

Во-первых, забудьте об использовании spy — if isValidInput , способного генерировать исключение, затем заставьте его генерировать исключение.

Если внутри используется соавтор, isValidInput() который может выдавать Exception , то издевайтесь над этим с помощью Mockito. Если это просто ваш код, то вы должны быть в состоянии настроить a так, чтобы он генерировал исключение.

Вам все еще нужно написать полный набор тестов для isValidInput() — investigate, используя expected опцию в аннотации @Test (я предполагаю, что вы используете JUnit здесь), чтобы указать, что создание исключения является ожидаемым результатом теста. Но, пожалуйста, не выбрасывайте Exception — используя его значимый подкласс 🙂

И, как прокомментировал @Dave Newton, тестирование var2 никогда не выйдет за рамки doStuff .

1. договорились о тестировании var2. скажем, я издеваюсь над сотрудником, чтобы создать исключение, смогу ли я собрать содержимое строки из моего блока исключений. Моим сотрудником является DefaultHttpClient.execute().

2. Если я использую ожидаемое изменение, метод doStuff() выдает исключение, но возвращает логическое значение. Итак, если мой модульный тест ожидает исключения определенного типа, он проглатывается.