Статьи

Как протестировать пользовательское исключение, используя пользовательские утверждения FEST

Ноябрь 20, 2018

 

Вступление

Это третья часть моих сообщений о проверке утверждений с использованием Fest, JUnit и пользовательских исключений. В первом посте рассматривались основы утверждений , затем продолжалось тестирование пользовательских исключений с использованием JUnit и класса ExpectedException в JUnit . На этом этапе вы должны знать, что у вас есть пользовательский класс Runtime Exception, и вы хотели бы протестировать его с помощью Fluent API, предоставляемого FEST.

Пользовательские утверждения с Fest

В этом сообщении блога не будет подробно рассказываться о создании пользовательского утверждения, но решение, опубликованное в проекте Github , содержит собственное утверждение. Кроме того, пожалуйста, обратитесь к официальному сайту документации .

Основываясь на последнем посте, вы увидите, что ExpectedException является значительным улучшением по сравнению с методами @Test (ожидаемого) и Try / Catch, однако объект ExpectedException все еще можно улучшить, добавив API в свободном стиле, поддерживаемый проектом Fest Assertion. , Так как вы это делаете? Давайте получим право на решение!

Ожидаемые исключения с FEST и JUnit @Rule

Теперь, когда у нас есть понимание утверждений FEST, функциональности @Rule в JUnit и @ExpectedFailure в ClickConcept, мы можем объединить первые два, чтобы обеспечить поведение ожидаемых исключений в стиле беглого стиля при тестировании класса утверждений с использованием аннотаций @ExpectedFailure.

Тестирование вашего пользовательского исключения с FEST

Давайте начнем с создания нового объекта @Rule « ExpectedException », который расширяет TestRule. При создании класса мы представим конструкцию через простой метод фабрики, чтобы вернуть новое ExpectedException. Фабрика по умолчанию вернет базовую реализацию, где функциональность отключена во всех других случаях, когда исключения нежелательны.

Сначала мы можем начать с кода, но я объясню, что для создания своего собственного пользовательского интерфейса Fluent API для FEST необходимо заново создать API для утверждения базового исключения. Свободный API, который вы создадите, будет в дополнение к классу подтверждения исключений FEST. Свободная справка по API была получена из нескольких блогов, но наиболее информативной была http://www.unquietcode.com/blog/2011/programming/using-generics-to-build-fluent-apis-in-java/ .

ПРИМЕЧАНИЕ. AbstractExpectedException инкапсулирует базовый API-интерфейс FEST для ExceptionAssertion. Код для этого можно найти на сайте Github: https://github.com/mike-ensor/fest-backed-expected-exception

public class ExpectedCustomException extends AbstractExpectedException<ExpectedCustomException> {

    private Integer code;

    public static ExpectedCustomException none() {
        return new ExpectedCustomException();
    }

    /**
     * Checks to see if the CustomException has the specified code
     *
     * @param code int
     * @return AbstractExpectedException
     */
    public AbstractExpectedException hasCode(int code) {
        // method telling class that a custom exception is being asked for
        markExpectedException();
        this.code = code;
        return this;
    }

    @Override
    protected void checkAssertions(Exception e) {
        // check parent's exceptions
        super.checkAssertions(e);

        if (getCode() != null) {
            // FEST Custom Assert object
            CustomExceptionAssert.assertThat(e).hasCode(code);
        }
    }

    private Integer getCode() {
        return code;
    }

}

Анализ

В этом примере мое CustomException предоставило «код» для хранения при создании исключения. Чтобы проверить это, мой пользовательский объект ExpectedException должен искать правильный код в объекте CustomException, в свободном поместье.

Вот пример тестового примера, который объясняет, как использовать ваш новый свободный тест API Custom Exception. Обратите внимание на третий тестовый пример, чтобы увидеть, как работает Fluent API! (ПРИМЕЧАНИЕ. Полные тестовые наборы доступны на моей учетной записи github .

public class CustomExceptionTest {

    @Rule
    public ExpectedCustomException exception =
            ExpectedCustomException.none();

    @Rule
    public ExpectedTestFailureWatcher expectedTestFailureWatcher =
            ExpectedTestFailureWatcher.instance();

    @Test
    public void hasCode_worksAsExpected() {
        exception.hasCode(123);
        throw new CustomException("Message", 123);
    }

    @Test
    @ExpectedFailure
    public void getCode_fails() {
        exception.hasCode(456);
        throw new CustomException("Message", 123);
    }

    @Test
    @ExpectedFailure
    public void getMessageAndCode_codeFailsFirst() {
        exception.hasCode(456).hasMessage("Message");
        throw new CustomException("Message", 123);
    }

}

Summary

Thank you to those of you who have read through this little series covering assertions, how to test exceptions (both the exception flow and custom exceptions) and then on to testing your custom exceptions using FEST assertions. Please come back to my blog in the near future where I will have a REST API checklist to look over when architecting your next REST API.

Those who are reading this blog are most likely a small subset of the software development community, but if you are not, and you find the idea of a fluent-API really cool (as I do), please check out the FEST assertion library. If you are new to test driven development, please take up the practice and try applying to your code immediately. If all developers used TDD as a general practice, the level in quality would grow world wide!

41
Share: