testomat.io управление авто тестамиСпасибо огромное всем, а то я действительно буквально понял, один тест, одно действие. И если есть возможность объясните, что понимается под фразой: “у вас должно быть как можно больше 100-1000 модульных тестов, ведь на стадии проверок модульных тестов, кроются большинство ошибок” ?
я куски теста убрал))))
покрывай как можно больше функционала))
100-1000 - условность, всё зависит от проекта)))
тут нужно найти “Аuгеа mediocritas” для колличество-качество
Тут речь идёт о юнит-тестах. Их пишут разработчики и эти тесты, в отличие от функциональных, проверяют не конечный функционал, а работоспособность модулей кода (классов, методов и т.д.), отсюда их название. Этих тестов, по-правильному, должно быть много, о чём и пишет автор.
Погугли на тему “пирамида автоматизации тестирования”, чтобы почитать подробнее
Не надо вводить людей в заблуждение такими утверждениями. Критерии определения функционала для покрытия автотестами - это очень важный вопрос для автоматизатора и ответ на него несколько сложнее того, что ты написал
На этом форуме уже тоже эту тему обсуждали не раз. Например, вот тут можно почитать:
От себя добавлю: ввиду того, что каждая организация выставляет свои шаблоны написания тест кейзов, нередко попадаются ситуации, когда в одном тесте может быть N проверок. Это не значит, что мы проверяем все подряд по ходу дела. Просто дойдя до конечного шага, мы осуществляем несколько проверок конкретного функционала. В техническом плане такое реализуется при помощи так называемых мягких ассертов, ибо в случае использования нескольких стандартных asserts, мы рискуем завалить тест уже на первой проверке, так и не узнав результат остальных.
Хотя, мне также помнится пример ручных тестов, написанных на стороне заказчика, в которых даже по ходу дела осуществлялись проверки. Т.е. сам шаблон представлял из себя набор instructional и verify степов. Каждому из верифай степов ассайнился приоритет. После выполнения запускался аналайзер, который учитывал некий минимально допустимый порог незначимых фейлов. Если по факту, их число превысило данный порог, тест считался зафейленым. В противном случае, отмечался как passed. И такие вещи приходилось автоматизировать. Тут уж без soft asserts вообще никак.
Собственно, сама идея “один тест - одна проверка” пошла как раз из юнит тестов. В случае же UI функциональных тестов, которые по сути являются системным / сис. интеграционным уровнем тестирования, - одной проверки зачастую может быть недостаточно, чтобы однозначно судить о работоспособности функционала. Посему, лично я не вижу ничего плохого в наличии нескольких проверок, если это комплексная часть верификейшена одного функционала.
Согласен, если комплексная, то это вполне нормально. Как пример, могу привести свой последний проект, где тесты проверяют выгружаемые XML-файлы. В тесте делается минимум две проверки:
- на количество выгружаемых файлов (в разных кейсах может быть выгружено различное количество)
- на содержимое файлов
Несмотря на то, что формально проверок 2, но это части единого теста, при провале любой из них тест считается проваленным.
То есть правило “один тест - одна проверка” надо воспринимать не буквально, а с оглядкой на тестируемый функционал и структуру тестов
Кстати в ответ на пример.
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. извините новичка за нубские вопросы =)
подгружать разные файлы либо SQL подключить для
я что-то в вопросе запутался…
если нужно проверить всё за раз - в одном
если нужно для каждого случая отдельно - туча тестов
Провокация.
Что до ваших примеров, еще раз повторюсь, такая реализация будет создавать больше вопросов и проблем, нежели профита.
1 лайк
Ну поэтому я и спрашиваю, как должна выглядеть модель теста проверки полей и чекбоксов, чтобы она не вызывала вопросов?
В общем, если используется PageObject, рекомендуется не обращаться к полям напрямую в коде теста.
Тем более, есть обходные пути. Например, хранить состояние контролов в специальном классе (называется Data Transfer Object). Обсуждение можно почитать тут:
А тут я постарался собрать заметки по Пейджобжектам: SWD.Starter/methodology_all_in_one_rus.md at master · dzharii/SWD.Starter · GitHub
Но, это лишь рекомендация. Т.е. правило, которое иногда можно нарушить.
Если вы объявляете и используете веб-элементы непосредственно внутри теста, то на этот случай такая рекомендация не распространяется.
@mindjin, у вас всего 500 полей и чекбоксов в приложении, распределенных по разным страницам или все на одной странице?
Если понять как выглядит ваше приложение, то это могло бы здорово помочь в том чтобы дать дельный совет.
Если приложение не публично и вы не можете сделать скриншот, то можно нарисовать схематически, например в Pencil Project:
Мое приложение это “админка” которая позволяет настроить конфигурацию для интерактивного телевидения. Поэтому я говорю о многочисленных текстовых полях, чекбоксов, комбобоксов итд. Скриншот есть в первом посте, но в открытый доступ выложить ее не могу.
В общем, если форма большая – то с ней всегда много рутинной работы.
Если в форме на одной странице действительно 500 полей – то и методов доступа, учитывая что нужен метод для установки и получения значения, может быть 1000.
Я бы хотел уточнить, именно на той странице, которая на скриншоте, действительно 500 элементов? Они все состоят в одном логическом блоке, или разделены на несколько логических блоков?
Нее я имел ввиду 500 элементов по всей админке учитывая разный Id. Поэтому очень интересует обращение к ним через тест.
А в чем польза этих 1000 геттеров/сеттеров? Стоит ли, так буквально, переносить все “правила хорошего тона” программирования на автоматизацию?
Пусть есть еще DTO - 500 филдов+1000 геттер/сеттер. Итого 500+1000+500+1000=3 000 филдов и методов для 500 реальных сущностей. С моей точки зрения, у автоматизации основная цель это отдача (КПД), а у этих 2000 методов она равна нулю.
Так предложите как будет задаваться обращение к полю и изменение его через сам тест? Я просто жду конкретного ответа чтобы исправить свой Framework.
P.S. Сейчас реализация например с попапами такая.
card.popup("Видеофильм", "Маруся") //попап сам определит какой это вид элемента, а также переключится на самый последний попап и применит к нему значение, в данном случае это текстовое поле
card.popup("Возраст", "+3") //это уже Dropbox
card.popup("Скидка", "on") //это Checkbox
Вместо того, чтобы “ждать конкретного ответа”, уже давно могли бы попробовать разные варианты и сделать для себя выводы. Вам уже кучу ссылок накидали с различными подходами, а вы все ждете готовенького решения.
Начнем с простого. Глядя на следующий код:
кто сможет ответить на вопрос: что собственно ваш тест тестирует? Абстрактные попапы какой-то мистической карты? Какие попапы? Алерты? Нотификейшены? Какой карты? Игральной? Гугл мэпс? Или может это профиль юзера? Тест должен отражать логику тестируемого сценария. Ваши 3 строки - это 3 компонента различных сущностей: Movie, User, Discount. Вы во всех своих примерах плюете на 4 фундаментальных концепции: OOP, DDT, PageObject, DSL. Любите функциональное программирование? Пишите на Scala. Плевать на основные концепции? Напишите свой DSL для автоматизации.
По теме:
configPage()
.fillInMovieInfo(movie)
.fillInUserInfo(user)
.fillInDiscountInfo(discount)
.submit();
Как заполнить поля на основании переданных данных - уже забота страницы, но уж никак не теста. Хотите нечто generic? Хотите избавиться от миллиона геттеров? Придумайте способ маппинга инкапсулированных элементов страницы + напишите generic verification модуль. Как это сделать? Out of scope данной темы.
О каком готовеньком решении идет речь, вы о чем вообще? Если бы внимательно прочитали тему, я твердо сказал, что мне не нужны готовые решения. Сначало остановился на Getter&Setter, но были сомнения. Я вас не прошу писать за меня код. Я прошу как новичку в программировании дать совет, что использовать (в крайнем случае что почитать)
P.S. например о геттерах и сеттерах я вообще только из этого форума узнал. Например реализация в одной из ссылок, очень интересная:
textField("Last Name").type(lastName);
textField("Phone").type(phone);
textField("Email").type(email);
textField("Username").type(userName);
textField("Password").type(password);
textField("Password again").type(password);
dropDownList("User Type").select(userType);
dropDownList("Reporting Level").select(reportingLevel);
checkbox("I agree").check();
но пока не совсем понимаю как она работает.