2017-02-15 12 views
2

Я пытаюсь проверить этот метод:Как утверждать, что метод void генерирует исключение с использованием Mockito и исключения catch?

public void deleteCurrentlyLoggedInUser(Principal principal) { 
    if (findLoggedInUser(principal) == null) { 
     throw new UserAlreadyDeletedException(); 
    } 
    userRepository.delete(findLoggedInUser(principal)); 
} 

Вот findLoggedInUser:

User findLoggedInUser(Principal principal) { 
    return userRepository.findByUsername(principal.getName()); 
} 

А вот мой тест до сих пор:

@Test 
public void shouldThrowExceptionWhenUserNotFound() { 
    // given 
    when(sut.findLoggedInUser(principalStub)).thenReturn(null); 

    // when 
    sut.deleteCurrentlyLoggedInUser(principalStub); 

    // then 
    catchException 
    verify(userRepositoryMock, never()).delete(any(User.class)); 
} 

Так как я ловлю исключение используя catch-exception здесь? Метод, который я тестирую, возвращает void, и я просто не могу найти способ утверждать, что это исключение найдено.

EDIT: Я знаю, что мог бы использовать: @Test(expected = UserAlreadyDeletedException.class), но я хочу переключить весь проект на исключение catch-exception, потому что он намного лучше, и использование ожидаемого в @Test не очень разумно.

+0

Не используйте 'expected = SomeException.class'. У вас нет контроля или видимости, над которым выражение в методе действительно вызывает исключение. Предпочтительно использовать 'try/catch' над этим, потому что тогда вы можете точно показать, что вы ожидаете делать. –

+1

@AndyTurner Я бы сказал, что если у вас есть несколько вещей, которые могут вызвать «SomeException» в одном блочном тесте, указанный модульный тест нужно разделить. –

+0

@JoeC да, но: за исключением самых простых тестов, вы, вероятно, делаете что-то, чтобы сделать свою тестовую конкретную настройку; в зависимости от того, что вы ловите, одно из этих действий по настройке может вызвать одно и то же исключение, создавая впечатление, которое проходит ваш тест, когда на самом деле это не так. –

ответ

0

Возможно, что использование правил - это то, что может сработать для вас?

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

Вы можете прочитать больше об этом аккуратной особенности junit4 здесь:

https://github.com/junit-team/junit4/wiki/Rules

Пример:

public static class HasExpectedException { 
    @Rule 
    public final ExpectedException thrown = ExpectedException.none(); 

    @Test 
    public void throwsNullPointerException() { 
      thrown.expect(NullPointerException.class); 
      throw new NullPointerException(); 
    } 
} 
1

Я никогда не слышал о броском исключении, но это Безразлично» t точно похоже на современную библиотеку: последнее обновление основного исходного кода (на момент написания) было on May 3 2015.

Если вы используете Java 8, и может использовать JUnit 4.13 или более поздней версии, вы можете использовать assertThrows:

assertThrows(
    UserAlreadyDeletedException.class, 
    () -> sut.deleteCurrentlyLoggedInUser(principalStub)); 

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

+0

Знаете ли вы, как я могу использовать Junit 4.13, когда я использую Spring Boot? Я пока не вижу эту версию в Maven Repo. – doublemc

+0

Эта функция также включена в JUnit 5, однако как 4.13, так и 5.0 еще не выпущены публично (по-прежнему в RC или Snapshot verison). Вот почему вы не можете найти версии на официальном maven repo :). – vegaasen

 Смежные вопросы

  • Нет связанных вопросов^_^