Здравейте на всички,
Искам за себе си, за да се разбере теорията. Къде е най-доброто и кога да се инициализира на водача.
Срещал съм се с няколко опции:
- в теста и да го премине в конструктора на страницата
- в теста, но преди провеждането на теста по такъв абстрактен testng
- в себе си (и, когато има позоваване на него повдига страница Driver) страница
Може би все още има някои интересни опции?
Харесва ми идеята да се изолира напълно логиката от драйвера за тест, но подозирам, че този метод може да има някои недостатъци.
Нито един от тези варианти не е правилна. Това, което описваш е специфичен модул домейн.
Това изглежда е правилният етикета си струва, и мислеше за изолацията вярно, но по мое мнение, първо трябва да се разбере, че има - рамка. и - защо тестовата страница и не разполагат с никакви връзка с тази концепция. И тогава може да се говори за това къде действителните трябва да бъдат изолирани WebDriver.
За приета рамка. Всъщност, намерих етикет, тъй като е най-близо до проблема (най-близо до тук трябва да се разбира така, че другите не са относими
Съгласен съм с позицията, че тестовата страница, и не са част от рамката.
Вярно е кадър. Сега нека да се опитаме да разберем това, което трябва да бъде рамката за да се гарантира, че посочената скорост и лекота на развитие, както и - надеждността на вашите изследвания, независимо от AUT?
На Сократ метод е сериозен
Това е, което аз не разбирам, ние все още се пристрастяват към нашите тестове на водача (дори ако тя е да направи всички в базовия клас).
Благодаря ви за вниманието ви към проблема.
А ти за примери, които противоречат на собствените си изводи не гледайте.
Да приемем, че имате водач манипулатор. който е разположен вътре в рамката.
Възникват няколко въпроса:
- На какво състояние инициализация / шофьор затваряне трябва да се проведе?
- Има изследвания, изисквани машиниста в рамките на разглеждания ниво на абстракция?
- Как рамка модули наистина нужда от шофьор?
- Как да се създаде гъвкава връзка между модулите, които се нуждаят от водач?
ако искате да задържите курсора на мишката и mimnimum прекарат половин година на стабилна писане обвивки на Селен и помощни програми за Proektika с autotests. След това трябва да бъде такива класове: BrowserFactory - с набор от функции на браузъра тях, някакви други действия на браузъра; WebDriverHolder - с instanced браузър; WebDriverInstances - които ще Seter браузър, хетеро vebdrayvera и като "InheritableThreadLocal", за да бъде в състояние да нарани многонишкови тестове.
И ако няма такова време за "svobododumiya" (въпреки че kostyleklepaniya като цяло), по-добро използване на готови решения селенид, JDI (epam), други готови freyvorki (обвивки на селен), или в Python свят RobotFramework
въпреки че Python не знае, че е по-добре да се използва, може да ви каже Pythonistas готови удобни рамки
Да започнем с това, ще даде отговор на въпроса за концепцията на вашата тестова приложение като цяло, как искате да се изгради и какви канони. Може би точно сега zakritikuyut, но автотест красотата и хармонията на кода, както и неговата скорост (преувеличени, тъй като повечето от нас не са в кода, но в търсене на елементи в страницата) имат малък дял. Тестовете трябва преди всичко да бъдат подкрепени. Да, кодът трябва да бъде добре, да има структурни свойства, които не Патерна (стр yelement), какво бихте направили, че не потъва, така че не трябва да бъде сложно кода, но просто и не тежка и лека (Александър Соловьов, здрасти за вас)
Сега за водача.
1. Ако не се придържат към едни или Paterno, ideomam и опит за използване на подход, DSL, може да премине като шофьор, навсякъде, да гледате лицето - много от тях са започнали, а след това се ozonavali глупост. Собствен опит също е необходимо.
2. Ако знаете, че работи на водача и е част от инфраструктурата конфигуриране, можете да ясно да опише лъжливо базовия клас на страниците си / от елементи. Въпреки това, вие също ще трябва да допълним класове сериозно основна функционалност за работа с елементи, това не винаги е удобно, но внимавайте и се възхищавам - как прозрачен DSL излезе.
3. Ако следвате стратегията на състава на вашата кандидатура, водачът ви мине като аргумент на основния клас, кандидатстване, както и за тестовете излагайте публичните методи и атрибути, които се предават на приложението като приспособление за изпитване черупка, която ще съществува до края на теста - заседателен хващане.
др IMHO: Вярвам, че всеки за себе си, ако той избере всеки удобен подход, защото тестовете за писане за него, и за да се поддържа, също. Ако развитието е отбор, а след това става с тях също трябва да се обърне внимание. И в двата случая, вие също трябва да се разбере, че рано или късно "тухла пада", и завършва работата, и след като някой друг ще го всички подкрепят, така че да направи същото по начин, който би имал ушите, че няма да изгори.
По отношение адски много умни програмисти и Дзен-кодиране, аз мисля, че тестовете трябва да бъдат написани, а не сложно изразява чрез използване на езиковите средства.
Интересно Tiomka стартира
На мобилното (Appium) разбрах, малко криво, чрез ApplicationManager:
дългосрочен експеримент с Файт и вероятно ще трябва да се променят по ENUM променливи и се отърви от тази loadConfigProp
ApplicationManager - тук имам екраните се инициализират и самата водача с Файт ..
Всъщност той е на екрана:
Това всъщност ми тест:
със сигурност намалява от трансевропейската транспортна мрежа, има все още имам контейнери, в които sostredatochena логика за различни устройства и различни имена и различни послания, но например, ще бъдат оценени ..
Започнах всичко писмено, когато няма nicherta разбирам, и току-що започваше да се разбере, автоматизация, така че не е много добре тук всичко се случи, а сега пренапише, така че всички очаквания и методи за компоненти на потребителския интерфейс - отнесени към отделните класове.
Това е така, под моята mobilku за Android, такава рамка, сега се смята, че тя не е толкова малко опит podnabralsya, пренапише. В мрежата ще има по-сложно място, там разбрах, многонишкова много браузъри и работи под различни операционни ..
Когато пишете рамка автоматизация за себе си открои неща като:
- всички код трябва да се използват повторно, така че Пейдж е бил само на елементите, и работи с тях
- при четене тест всичко трябва да бъде много ясно, че е налице
- водача и очакванията не трябва да са в теста и не трябва да бъдат в Page
- всички методи, свързани elemntov - трябва да са в своя клас
- всички методи на очакванията - трябва да се съхраняват в своя клас
- рамка трябва да бъде написано така, че за първи път проектиран теста, но тъй като тя има вече генерирани методи. Просто мисля, че на теста както трябва да бъде, и след това да напишете методите за тестване
- трябва да се спазва навсякъде нива на достъп
И аз се инициализира шофьор TestBase клас, от която всички тестове и инициализация се случва, когато изпълнявате теста)
Човек трябва да се разбере концепцията да се започне. И ти го хвърлим повече код.
Duck нека Анализиране просто на такива примери може да се покаже какво е добро и какво е лошо ..
А много често решение, аз направих така
И как са нещата сега?)
Направих и не) Просто се опитваме да опишем друг интересен подход от практиката:
Дължина на водача има Сингълтън инициализация (заточени на Firefox)
Тъй като има EnvironmentConfiguration клас произход на водача за бъдещи нужди
След това е абстрактно Страницата, която съдържа общи методи за работа с страниците и в конструктора създава конфигурационен файл, който на свой ред се стяга на водача
След това от тази страница наследил всички страници. При изпитването на страница, и го предал конфигурация.
Тъй като аз се радваше jbehave в конфигурацията клас базовата тест, така
като цяло, инициализация на водача трябва да се прави само извън тестовите страници и предмети или компоненти, но го направи така, че това е водачът juzat не само BaseScreen. но също така е възможно да се juzat и други Клаес. Има много различни подходи.
Най-големият проблем, може би - е, че в BasePage трябва да се натрупват всички методи на работа с Пейдж, често установяването на методи очаквания, методи са свързани с кликване и всичко останало, което не е добро, защото тя е по-добре да споделите на този принцип:
- методи за работа с елементите се намират в своя клас
- Методи очаквания в своята
- методи са обобщени за повторна употреба в други sreens всички или почти всички - лежи в BasePage
в Java не е множествено наследяване, така че може да наследи само BasePage. което ще се основава само на общи методи за всички екрани. Методи за работа с елементи, които вече там не се натрупват. Оказва се, че е необходимо или се планират, или да направите каскадни наследство: - UiElements наследени от WaitingElementsts. WaitingElements от своя страна наследява от BasePage който реализира за водача и така водачът преминава теста.
Помощта може да дойде помощници, но те ще трябва да се дръпне на теста не е много хубаво ..
Това е може би защо водачът трябва да бъде изолиран от теста и страници, тъй като тя ще започне в различни Klas молбата си и всичко, което трябва да работи ..
Дори и да се направи снимка на слушателя, че трябва да използвате драйвера там. Но тестовете вече са приведени juzat изпълнение с този драйвер. Това не е да се притеснявате за водача, защото това ще направи рамка за вас ..
Инициализация на водача - на практика това е едно предизвикателство getDriver
За съжаление за непредвидено прекъсване.
И все пак, бих искал да донесе на дискусията, на която логично точка.
Така че, по мое мнение:
Състояние за започване е да стартирате драйвера на тест или група от тестове
Тест пилотът не е необходимо.
Шофьор необходимо poidee страници и компонентите, които работят с страниците, а водачът може просто да прехвърли разходите назад.
В мотивите е по-малко вярно?
Състояние за започване е да стартирате драйвера на тест или група от тестове
Нека започнем с факта, че водачът не се изпълнява тестовете и браузъра. Тестове стартира единица рамка (например, testng / JUnit). За шофьорите, че е важно да не "какво" и "къде и кога". В този случай, "където" - в контекста на безопасно изолиран резба. "Когато" - например, на [самостоятелна, тестове, клас, методът]. Тук можете незабавно и задача - да се разбере кога е най-добре да се вдигне на водача.
Шофьор необходимо poidee страници
И това, което страници нужда от шофьор? Страници - слой от вашия домейн, а шофьорът - рамката. Ако извадите водачът на ниво страница, че е по-добър от използването му в самите тестове.
Нека започнем с факта, че водачът не се изпълнява тестовете и браузъра.
Да, разбирам, че водачът не работи тестове :). Исках да напиша, че състоянието да се инициализира на водача - текущи тестове. В момента тече теста, а също така трябва да бъде стартиран на водача. Докога няма значение.
И това, което страници нужда от шофьор? Страници - слой от вашия домейн, а шофьорът - рамката. Ако извадите водачът на ниво страница, че е по-добър от използването му в самите тестове.
Страници нуждаят от водач, защото страниците с помощта на методите на водача правят нещо на основно ниво - методи позволяват да работите с елементи на страницата и да извършва някакво действие. Как мога да се намали зависимостта на страницата на водача?
Страници нуждаят от водач, защото страниците с помощта на методите на водача правят нещо на начално ниво
Т.е. ако имате 10 страници, както и всичко, което трябва да въведете стойност в полето за въвеждане, ще дублира всяка страница driver.findElement (локатор) .sendKeys (текст) по отношение на всяко поле, нали?
Свързани статии