Структура и организация тестов (Аннотация @Test)

общие вопросы
#1

Здравствуйте, очень хотел бы узнать про саму организацию тестов, так как не совсем понятно как в коде это должно выглядеть. Прочитал несколько статей (например: Девять кругов автоматизированного тестирования) по организации тестирования и все вроде бы понятно, но на деле получилось совсем иначе. На сайте написано "
Один тест — одно действие. Исключений не больше 5%" когда мы пишем аннотации @Test в классе, они должны быть взаимосвязаны? Сейчас, я понимаю это так:

  1. В классе мы выполняем определенное действие с проверками (проверка текстового поля)
  2. С помощью аннотаций @Test мы выполняем действия как если бы мы тестировали вручную (Изменить поле, посмотреть что после сохранения оно поменялось. Ввести другое значение в это поле и др.)

Но аннотации @Test выполняются не по порядку и из-за одной аннотации могут пофейлится все в классе, вообщем я немного запутался как в коде я должен писать тесты. Спасибо.

P.S. для примера прилагаю скриншот карточки, которую нужно протестировать.

1 лайк
#2

Скорее всего автор статьи не так выразился и имел ввиду “один тест - одна проверка”. Короче, автотест - это тот же ручной тесткейс. Он должен производить одну определенную проверку и возвращать результат успешности проверки (обычно реализуется через assert-ы)

В случае твоей формы тесты я бы организовал, например, так (допустим на скриншоте форма добавления информации по видеофильму):

class AddVideoFormTestSuite {

  @Test
  public void testFillAllFields() {
    // TODO тест на проверку успешного добавления фильма, когда заполнены все поля
  }

  @Test
  public void testFillObligatoryFields() {
    // TODO тест на проверку успешного добавления фильма, когда заполнены только обязательные поля
  }

  @Test
  public void testObligatoryFields() {}
    // TODO тест на проверку заполненности обязательных полей формы (failure-сценарий, когда проверяется реакция системы на незаполненное обязательное поле)

  @Test
  public void testAddDublicate() {
    // TODO тест на проверку попытки добавить фильм, который уже есть
  }

...

}
1 лайк
#3

ещё один небольшой пример:

//    @WithDriver("chrome")
    @WithTag("register_user")
    @Test 
    public void RegisterUser() throws InterruptedException
    {
        step.start_browser();
        JavascriptExecutor jse = (JavascriptExecutor)driver;
        jse.executeScript("window.scrollBy(0,400)", "");
        step.input_user_name(TestUtils.randomUserName());
        step.input_password(user.getProperty("Password"));
        step.input_confirm_password(user.getProperty("RePassword"));
        select_language();
        step.input_first_name(user.getProperty("FirstName"));
        step.input_last_name(user.getProperty("LastName"));
        select_title();
        step.input_email(email);
        step.input_confirm_email(email);
        jse.executeScript("window.scrollBy(0,400)", "");
        select_for_register();
        step.click_on_terms_check_box();
        jse.executeScript("window.scrollBy(0,200)", "");
        step.click_on_become_a_member_button();
        //Thread.sleep(10000);
    }
#4

Спасибо огромное всем, а то я действительно буквально понял, один тест, одно действие. И если есть возможность объясните, что понимается под фразой: “у вас должно быть как можно больше 100-1000 модульных тестов, ведь на стадии проверок модульных тестов, кроются большинство ошибок” ?

#5

@Beliy_Ruslan, по “феншую” в тесте должна быть как минимум одна проверка :wink:

#6

я куски теста убрал))))

#7

покрывай как можно больше функционала))
100-1000 - условность, всё зависит от проекта)))
тут нужно найти “Аuгеа mediocritas” для колличество-качество

#8

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

Погугли на тему “пирамида автоматизации тестирования”, чтобы почитать подробнее

#9

Не надо вводить людей в заблуждение такими утверждениями. Критерии определения функционала для покрытия автотестами - это очень важный вопрос для автоматизатора и ответ на него несколько сложнее того, что ты написал

На этом форуме уже тоже эту тему обсуждали не раз. Например, вот тут можно почитать:

#10

От себя добавлю: ввиду того, что каждая организация выставляет свои шаблоны написания тест кейзов, нередко попадаются ситуации, когда в одном тесте может быть N проверок. Это не значит, что мы проверяем все подряд по ходу дела. Просто дойдя до конечного шага, мы осуществляем несколько проверок конкретного функционала. В техническом плане такое реализуется при помощи так называемых мягких ассертов, ибо в случае использования нескольких стандартных asserts, мы рискуем завалить тест уже на первой проверке, так и не узнав результат остальных.

Хотя, мне также помнится пример ручных тестов, написанных на стороне заказчика, в которых даже по ходу дела осуществлялись проверки. Т.е. сам шаблон представлял из себя набор instructional и verify степов. Каждому из верифай степов ассайнился приоритет. После выполнения запускался аналайзер, который учитывал некий минимально допустимый порог незначимых фейлов. Если по факту, их число превысило данный порог, тест считался зафейленым. В противном случае, отмечался как passed. И такие вещи приходилось автоматизировать. Тут уж без soft asserts вообще никак.

Собственно, сама идея “один тест - одна проверка” пошла как раз из юнит тестов. В случае же UI функциональных тестов, которые по сути являются системным / сис. интеграционным уровнем тестирования, - одной проверки зачастую может быть недостаточно, чтобы однозначно судить о работоспособности функционала. Посему, лично я не вижу ничего плохого в наличии нескольких проверок, если это комплексная часть верификейшена одного функционала.

#11

Согласен, если комплексная, то это вполне нормально. Как пример, могу привести свой последний проект, где тесты проверяют выгружаемые XML-файлы. В тесте делается минимум две проверки:

  1. на количество выгружаемых файлов (в разных кейсах может быть выгружено различное количество)
  2. на содержимое файлов

Несмотря на то, что формально проверок 2, но это части единого теста, при провале любой из них тест считается проваленным.

То есть правило “один тест - одна проверка” надо воспринимать не буквально, а с оглядкой на тестируемый функционал и структуру тестов

#12

Кстати в ответ на пример.

step.input_user_name(TestUtils.randomUserName());
step.input_password(user.getProperty("Password"));

Хотел бы такую вещь спросить, вот у меня есть 500 элементов (каждый имеет 1 из 4 типов), судя из примера, нужно писать 500 методов? (Имя, Номер, Страна)

В своем методе я очень сомневаюсь, так как если взять пример текстового поля:

card.edit(textField.name,"123");

То в уроках говорится, что не надо обращаться к элементам напрямую.

Взять другой метод

card.edit("Имя","123");

Но опять же, мы обращаемся непосредственно к имени поля (хоть внутри метода у нас используется правильный локатор). Тоже как то странно выглядит.

Подскажите, как должна выглядеть например, строка редактирования поля и чекбокса в главном тесте, учитывая, что полей и чекбоксов (500 штук). Описание метода мне не нужно, именно сама строка в тестах. Спасибо.

P.S. извините новичка за нубские вопросы =)

#13

подгружать разные файлы либо SQL подключить для

я что-то в вопросе запутался…

если нужно проверить всё за раз - в одном
если нужно для каждого случая отдельно - туча тестов

#14

Провокация.
Что до ваших примеров, еще раз повторюсь, такая реализация будет создавать больше вопросов и проблем, нежели профита.

1 лайк
#15

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

#16

В общем, если используется PageObject, рекомендуется не обращаться к полям напрямую в коде теста.

Тем более, есть обходные пути. Например, хранить состояние контролов в специальном классе (называется Data Transfer Object). Обсуждение можно почитать тут:

А тут я постарался собрать заметки по Пейджобжектам: SWD.Starter/methodology_all_in_one_rus.md at master · dzharii/SWD.Starter · GitHub

Но, это лишь рекомендация. Т.е. правило, которое иногда можно нарушить.

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

@mindjin, у вас всего 500 полей и чекбоксов в приложении, распределенных по разным страницам или все на одной странице?

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

http://pencil.evolus.vn/

#17

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

#18

В общем, если форма большая – то с ней всегда много рутинной работы.
Если в форме на одной странице действительно 500 полей – то и методов доступа, учитывая что нужен метод для установки и получения значения, может быть 1000.

Я бы хотел уточнить, именно на той странице, которая на скриншоте, действительно 500 элементов? Они все состоят в одном логическом блоке, или разделены на несколько логических блоков?

#19

Нее я имел ввиду 500 элементов по всей админке учитывая разный Id. Поэтому очень интересует обращение к ним через тест.

#20

А в чем польза этих 1000 геттеров/сеттеров? Стоит ли, так буквально, переносить все “правила хорошего тона” программирования на автоматизацию?
Пусть есть еще DTO - 500 филдов+1000 геттер/сеттер. Итого 500+1000+500+1000=3 000 филдов и методов для 500 реальных сущностей. С моей точки зрения, у автоматизации основная цель это отдача (КПД), а у этих 2000 методов она равна нулю.