Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Где и как лучше хранить сообщения об ошибках

webdriver
java
Теги: #<Tag:0x00007f7b7044fca8> #<Tag:0x00007f7b7044fa78>

(Eugene Moskalenko) #1

Не нашел более подходящего раздела под свой вопрос. Решил задать его здесь.

Подскажите пожалуйста, как лучше писать текст ошибки в тестах?

1. текст ошибки указывать в самом тесте (мой вариант)

    @Test(enabled = true, priority = 20)
    public void errorWhenNotRegisteredEmail() {
        // --------------------- Test Data ----------------------//
        String name = Random.generateRandomEmail();
        String pass = "valid_password";

        // --------------------- Test Case ----------------------//
        openLoginPage().loginAs(name, pass).loginFormMessages()
                .shouldHave(text("× Looks like that email address is not " +
                        "registered yet. Try to register or retype again."));
    }

2. текст ошибки указывать в классе объекта страницы, на которой выводится (иная точка зрения)

Исходя из такой логики -> "текст ошибки пренадлежит как бы странице, на которой выводится"

    @Test(enabled = true, priority = 20)
    public void errorWhenNotRegisteredEmail() {
        // --------------------- Test Data ----------------------//
        String name = Random.generateRandomEmail();
        String pass = "valid_password";

        // --------------------- Test Case ----------------------//
        openLoginPage().loginAs(name, pass);
        assertTrue(signInPage.isErrorWeDoNotRecognizeDisplayed());
    }

Что думаете по этому поводу?


Какой должна быть идеальная структура проекта автотестов?
(Sergey Korol) #2

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


(asolntsev) #3

Нет, если я правильно понял, во втором случае тоже проверяется текст ошибки, просто эта проверка делается внутри метода isErrorWeDoNotRecognizeDisplayed().

На первый взгляд мне кажется, что второй вариант правильнее, именно исходя из логики “текст ошибки принадлежит как бы странице, на которой выводится”.


(Sergey Korol) #4

Так shouldHave ведь возвращает SelenideElement, а вызывается assertTrue, т.е. в таком случае там либо стринги через equals сравниваются, либо shouldHave оборачивается в try / catch . Хотя, есть еще один извращенный вариант проверки на isDisplayed по локатору, в который вшит сам текст ошибки. :slight_smile:

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


#5

Попробуйте представить что будет, когда у вас упадёт тест.

В первом варианте вам покажет что текст такой-то не соответствует ожидаемому такому-то.

Во втором что false не равно true. Вот это откровение!
Вам при каком варианте понятнее и легче жить?

http://software-testing.ru/library/testing/testing-automation/2371-give-your-automated-checks-voice


(Eugene Moskalenko) #6

мне при первом, я первый вариант использую…


#7
    @Test(enabled = true, priority = 20)
    public void errorWhenNotRegisteredEmail() {
        // --------------------- Test Data ----------------------//
        String name = Random.generateRandomEmail();
        String pass = "valid_password";

        // --------------------- Test Case ----------------------//
        openLoginPage().loginAs(name, pass);
        assertTrue(signInPage.isErrorWeDoNotRecognizeDisplayed());
    }

на мой взгляд текст ошибки не принадлежит странице
страница как объект спрашивает сервис и получает ответ, который она отображает (я предполагаю что она спрашивает сервис, а не содержит все логины системы в себе и не валидирует их на клиентской стороне)
т.е. она не хранит данные об ответе в себе, она их только получает и передает

соответственно страница signInPage может иметь вместо isErrorWeDoNotRecognizeDisplayed метод loginResponseMessage, который возвращает строку которую вы будете сравнивать с ожидаемой

Ожидаемая строка может храниться или в классе тестов для логина как строка, если больше никакие классы не тестируют эту фичу

    static final String EMAIL_IS_NOT_REGISTERED = "× Looks like that email address is not " +
                        "registered yet. Try to register or retype again.";

    @Test(enabled = true, priority = 20)
    public void errorWhenNotRegisteredEmail() {
        // --------------------- Test Data ----------------------//

        String name = Random.generateRandomEmail();
        String pass = "valid_password";

        // --------------------- Test Case ----------------------//
        openLoginPage().loginAs(name, pass);
        assertEqual(EMAIL_IS_NOT_REGISTERED, signInPage.loginResponseMessage());
    }

Или лежать в отдельном файле\классе, который хранит все сообщения системы
Так сказать репозиторий сообщений системы


    @Test(enabled = true, priority = 20)
    public void errorWhenNotRegisteredEmail() {
        // --------------------- Test Data ----------------------//

        String name = Random.generateRandomEmail();
        String pass = "valid_password";

        // --------------------- Test Case ----------------------//
        openLoginPage().loginAs(name, pass);
        assertEqual(Messages.EMAIL_IS_NOT_REGISTERED, signInPage.loginResponseMessage());
    }

Иметь метод loginResponseMessage более дальновидно, так как могут быть ещё другие сообщения при неудачном логине, например “Your login was existing but was deleted, sign in with the new one” etc
И для каждого из них писать булевый метод скучно и накладно.

Иметь класс Messages так же более дальновидно, если у вас есть кроме UI тестов ещё и интеграционные, или для мобильного UI, который имеет свои объекты страниц, но при этом разрабатываются в том же проекте и могут юзать те же сообщения при валидации того же теста, просто на другом уровне\пользовательском интерфейсе.

А если их нет и не предвидится, то и время тратить на этот over engineering нету смысла.

Надеюсь понял ваш вопрос правильно и ответил в кассу.