MRCEK: jj, Drag and Drop (record / playback) approach se hodi tam, kde se ti applikace moc nemeni a ne tam, kde probiha neustali vyvoj, protoze pak potrebujes scripty delas mene nachylne na neustale zmeny. Taky zalezi jake typy testu delas, pokud nake detailnejsi integracni testy, tak se bez codingu neobejdes, u e2e testu mozna jo.

Problemu jsme resili za ty roky samozrejme mraky, ale to bylo spise nasim specifickym prostredim, applikaci atd. Co se Ranorexu tyce, tak me nic extra nanapada.

FOLAS: já jsem začínal čistě jen drag and drop a nastavování akcí. Pokud ale člověk chce nějaké solidní a hlavně správné validace, nebo smysluplné test steps, tak se tomu UserCode nevyhne. Téměř nikdy se bez IF ELSE neobejdu abych se dostal na preconditions testu z jakéhokoliv stavu appky. Takže jasně, Cosi nenakoduješ, to nemáš... ;-)

Ještě jsem se ale chtěl zeptat, máš nějakou radu, čemu se vyhnout a může být později kritický problém? Myslím z tvých vlastních zkušeností...

MRCEK: Jak rikam, prakticke testovani s mobilnima appkama nemam, ale muzu rict, ze pro web. applikace je UserCode pouzitu > 75 procent myslim.

MRCEK: tak jestli to umí pracovat jenom s GUI, je to asi problém... Na druhou stranu, pokud nepotřebujete k testům klávesnici a netestujete ji, možná by stálo za to uvažovat o nějaké řešení typu custom keyboard, kdy klávesnice bude tak malá, aby nepřekážela

KID_MCHUTT: to je trochu problém si to hlídat, jde jen přes screenshot a tam právě dělá problém to zpoždění, já na mobilu už klávesnici nevidím, ale když udělám screenshot z ranorexu, tak tam ještě ta klávesnice je
Nevím jestli problém dělá nějak adb protokol, USB debugging mode nebo co vlastně. Paradoxně na Xiaomi Redmi2 je ta appka rychlejší než na Nexus6P, takže netuším, kde začít hledat problém.

MRCEK: tak jasně :) na druhou stranu, nějak si to hlídat musíš a pokud je jediná rozumná možnost hlídání si, jestli mi klávesnice zakrývá prvek...

KID_MCHUTT: nejde, protože ta klávesnice není stejná aplikace jako kterou testuji a není stejná na každém zařízení. Navíc to běží pod Ranorexovou appkou a je to celé zpomalené, takže ta odezva je někdy trošku divná, klávesnice už je schovaná, ale ranorex ji tam pořád vidí, například 1,5 s rozdíl než ranorex pozná, že už tam není.

MRCEK: a wait na schování klávesnice nejde? (neznám Ranorex)

FOLAS: Já jsem s tím před měsícem začal a čím víc tomu rozumím, tím je to horší... :-) Nakolik musíš používat UserCode? Já v podstatě u 75% test case, ale víceméně dost podobné kódy. Docela to umí dost věcí, ale u mých testů mám problémy se systémovou klávesnicí. Pokud někde něco Ranorex zadává jako text, tak vyskočí klávesnice a než se zase schová, tak mi někdy Ranorex neudělá touch na následující element. Prodleva je pokaždé jiná, takže je to na houby. Element je pořád viditelný a pořád valid (takže ani wait for mi nepomůže) ale Ranorex jej nějak nechce najít. Nesetkal jsi se s tím nebo něčím podobným?

MRCEK: Zatim ne, ale casem budem pokryvat mobilniho clienta pro Dynamics CRM.

FOLAS: Ahoj, můžu se zeptat, testujete v Ranorexu i mobilní appky?

TAUSINUS: Cau, my delame uz tak 2 roky v Ranorexu.

Zdravím, je tu někdo kdo má zkušenosti s automatickými testy v Ranorexu? Sháníme levnější variantu TestCompletu - máme už zastaralou verzi, tak hledám info pro a proti, díky

LEIN: diky :) development v tomhle pripade je cista nova instance pustena v docker kontejneru, nalejt dovnitr data pres unit testy (tam ty e2e testy mame, ale koukaj jenom na api/rest), pak pustit tu aplikaci a klikat do ni necim .. a ve stagingu/produkci si vystacime s tim jednoduchym scenarem, co jsem psal

URPUTNIK: nezbyva nez poprat hodne stesti :D automatizovane testy jsou peklo, pokud neni radny development proces vcetne managementu ;)

testovat v development prostredi je sebevrazda :) doporucuji mit vyhrazene uzavrene QA prostredi, pripadne development behem testu "uzamknout".

REST je ted mega popularni koukam

LEIN: jop, je to staticka webova aplikace napsana prevazne v Reactu a s backendem komunikuje pres REST .. vlastni tool si prave psat nechci, stejne tak nechci instalovat selenium :)

smoke testy jsou pro nas 'povinne' kvuli continuous deploymentu, to nikdo nebude neustale dokola testovat :)

pro smoke testy v produkci jsme se v tymu dohodli, ze bude stacit
a) pokud overime ze je cely vysledek buildu spravne deploynuty (buildime to webpackem a pouzivame lazy-loading, takze je to balik js souboru), takze budu overovat, ze existuji konkretni url
b) zakladni use case, kdy udelame request na rozhrani kde bezi aplikace .. ona si neco prochrousta a mela by nas presmerovat na login stranku (kvuli SSO v ramci korporace)
c) dalsi UC se budou testovat uz v development/staging prostredi, pac na ne potrebujeme pripravit data, jejichz generovani je kapitola sam o sobe

a+b by se dalo napsat treba v shellu, ale kvuli c) bych rad vybral neco, z ceho se dalsi generace nezblazni :)

URPUTNIK: "react aplikace" :)
myslis teda webovou aplikaci, ktera vyuziva react knihovny pro javascript ?

Ja si na FE testy napsal vlastni tool v pythonu se seleniem...pisu si scenare jednoduse krok za krokem (prikaz, parametry).

Bohuzel se to moc v praxi nepouziva - "Smoke testy" nedelame., alebrz akceptacni, ve kterych je obsazen test funkcionalit a celeho prostredi, ty obvykle delame rucne. Na pojmy nejsem.

Automatem jen kontroluji dlouhodobejsi veci, u kterych se mi nechce sedet :D

Pokud bude vase aplikace staticka - prvku se nemeni, jen data - automat se hodi.
Pokud budete "aplikaci" = stranky upravovat, pak budes (NEJSPIS) akorat porad predelavat automat.

Pokud to budou dotazy na urovni GET a kontrola parsovanim responsu...no tak...to se pro FE nehodi, ale na stressy ok:)

URPUTNIK: ano, mas pravdu, potrebuje to Selenium Server ;)

VYGIDOR: chm, ale to potrebuje Selenium server, ne? ten nemame :)

URPUTNIK: do it simple - nightwatch .)