Size: a a a

QA — Автоматизация

2020 August 08

MK

Mem Kekovich in QA — Автоматизация
Boris Osipov
ага поищи
Лол внатуре уже не обязательно :( Ток именн в жюните5 не нашёл чтобы указывалось
В градл емнип класспасс парсится по аннотации тест, мавене тест в названии класса бай дефолт ищется или явно указывать в конфиге
источник

AP

Anton Pavlov in QA — Автоматизация
Yuri Ivanov
Я просто думал, что @antonppavlov задает конкретный, практический вопрос. И если ему реально надо 150 полей заполнять и потом также зеркально проверять, то ему проще сделать отдельный тестовый шаг, в котором через PageObjects это будет делаться. А потом заюзать его в тестах. И там уже будет неважно напрямую он показывает внутренности PageObject, делает это через "API" или каким-то хитрым способом. В таком случае, вся "хрупкость" будет ровно в одном месте, а не размазана в десятке мест.
интересно.. в теории можно это сделать через 3 метода.. но добавить enum которым будет передаваться название веб элемента... в теории тогда в enum и локатор добавить можно... и потом в методе и сам объект созавать. Но опять же получается что оч много как буд-то бы уже логики проверок идет в  pageObject.  И не усложнит ли это все
источник

YI

Yuri Ivanov in QA — Автоматизация
Anton Pavlov
интересно.. в теории можно это сделать через 3 метода.. но добавить enum которым будет передаваться название веб элемента... в теории тогда в enum и локатор добавить можно... и потом в методе и сам объект созавать. Но опять же получается что оч много как буд-то бы уже логики проверок идет в  pageObject.  И не усложнит ли это все
Что я могу сказать? Написать меньше кода, чем нужно для установки полей и их проверки... ну это невозможно :) Придется написать столько сколько нужно. А все эти махинации с enum по объему выйдут точно также, как и другие варианты.
У вас же, главная задача, эту большую бяку, которая потенциально может измениться, грамотно инкапсулировать, чтобы в случае изменений, делать их в как можно меньшем кол-ве мест, в идеале, в одном.
источник

Н

Наиль in QA — Автоматизация
Начинаю изучать тестирование API и не понимаю, а какие тесты писать?
Первым делом хочу написать GET запросы на популярные страницы сайта.
А потом POST на авторизацию/регистрацию.

Что можете предложить далее?
Ну и вообще, есть ли смысл писать GET на 200 статус всех страниц?
источник

СС

Сказочный Сникерс... in QA — Автоматизация
Наиль
Начинаю изучать тестирование API и не понимаю, а какие тесты писать?
Первым делом хочу написать GET запросы на популярные страницы сайта.
А потом POST на авторизацию/регистрацию.

Что можете предложить далее?
Ну и вообще, есть ли смысл писать GET на 200 статус всех страниц?
Может начать просто с тестирования, если уже такие вопросы?
источник

СС

Сказочный Сникерс... in QA — Автоматизация
Не могу ответить на этот вопрос ибо меня снова забанят
источник

СС

Сказочный Сникерс... in QA — Автоматизация
Я просто не вижу разницы ручное/авто/авто ui/авто api
источник

YI

Yuri Ivanov in QA — Автоматизация
У вас вопрос не по теме автоматизации, а больше из плоскости тестовой аналитики.
источник

YI

Yuri Ivanov in QA — Автоматизация
Того, как правильно выбрать то, что тестировать и в каком объеме.
источник

YI

Yuri Ivanov in QA — Автоматизация
Делать это можно по-разному. Например, с помощью приоритезации. Узнайте, какие API методы чаще всего ломаются или какие являются для вашей системы самыми критичными.
источник

YI

Yuri Ivanov in QA — Автоматизация
Потом изучите это API и продумайте оптимальный набор тест-кейсов для тестирования всего этого.
источник

YI

Yuri Ivanov in QA — Автоматизация
В завершении оцените сколько на автоматизацию этого дела уйдет времени, равно как и на поддержку написанного.
источник

YI

Yuri Ivanov in QA — Автоматизация
А дальше с командой решите, стоит ли оно того.
источник

AS

Andrei Solntsev in QA — Автоматизация
Yuri Ivanov
Поля внутри PageObject'ов - это детали реализации. Если выпячивать детали реализации и напрямую к ним обращаться из тех же тестов, это делает такой класс, к которому обращаются, хрупким и плохо изменяемым. Поэтому и делают все эти геттеры, шметеры и прочее. Классика ООП :)
Если же мы говорим в целом про PageObject/PageElement, как паттерн, то по сути тот или иной PageObject/PageElement просто предоставляет API к странице/элементу страницы. И вот этим API и надо пользоваться, а не завязываться на реализацию, которую кто-то по неосторожности оставил открытой :)
Геттеры - это как раз не ООП.
Один из главных принципов ООП - инкапсуляция, т.е. сокрытие реализации. А геттеры наоборот, раскрывают детали реализации. Ещё раз: это не лучше, чем тупо оставить пустые поля.
источник

B

Bola in QA — Автоматизация
Вроде наоборот, мне на первых уроках джава говорили, что геттеры/сеттеры как раз инкапсуляция). То есть мы не даем прямой доступ.
источник

YI

Yuri Ivanov in QA — Автоматизация
Andrei Solntsev
Геттеры - это как раз не ООП.
Один из главных принципов ООП - инкапсуляция, т.е. сокрытие реализации. А геттеры наоборот, раскрывают детали реализации. Ещё раз: это не лучше, чем тупо оставить пустые поля.
Как раз скрывают и дают возможность подменить обращение к простому полу, обращением к более сложным сущностям, с попутными вычислениями, блекджеком и прочими плюшками. Но не будут спорить. Это споры бесполезные и в Java вызваны тем, что нет у Java синтаксического сахара Property, как в C# или Python и многим просто надоело писать сеттеры и геттеры :) И обычно такие споры идут вокруг POJO, где сеттеры и геттеры - это просто устоявшаяся исторически прослойка и никакой логики не предполагающая.
источник

СК

Сергей Кузнецов... in QA — Автоматизация
А можно пожалуйста определение инкапсуляции в студию?
источник

VB

Vlad Bak in QA — Автоматизация
о боже, снова инкапсуляцию подменяют сокрытием
источник

YI

Yuri Ivanov in QA — Автоматизация
Чтобы еще больше подкинуть на вентилятор? 😂 А потом еще подкинуть, что ООП в Java - не тру ООП. То ли дело батино ООП из Smalltalk на прототипах.
источник

B

Bola in QA — Автоматизация
И вообще, ООП умирает). Подкину сильнее.
источник