ugrás a tartalomhoz

Nightwatch.js - Selenium JavaScript-tel

T.G · 2014. Már. 8. (Szo), 19.35
Egy új projekt, amelynek segítségével JavaScript utasításokkal vezérelhetjük a Seleniumot
 ■
1

Többet tud a WebDriverJs-nél?

inf · 2014. Már. 8. (Szo), 23.59
Többet tud a WebDriverJs-nél?
2

Egyszerűség

T.G · 2014. Már. 9. (V), 08.58
Már régóta nézegettem a különböző projekteket:
http://theintern.io/
https://github.com/angular/protractor
http://webdriver.io/
http://casperjs.org/

Szerintem mivel mindegyik a Selenium-ot hajtja meg, így komoly különbségek a működésben biztosan nem lesznek. Ami engem megfogott a Nightwatch.js-ben, hogy náluk az egyszerű szintaxis különösen fontos volt. Nem kell olyanokat leírni, hogy: driver.findElement(webdriver.By.name('btnG')).click(); Elegendő csak annyi, hogy client.click('button[name=btnG]');

Néhány évvel ezelőtt még fel sem merült benne, hogy Selenium tesztet ne programozók készítsék. Ma már egy HTML-t, CSS-t ismerő embernek gond nélkül oda merném adni a Nightwatch.js-t, minimális tanítás után könnyedén tudná gyártani a teszteket. Ezt érzem én előnynek. Tudásban biztos nincs előnye.
3

Én a protractort nézegettem

inf · 2014. Már. 9. (V), 09.45
Én a protractort nézegettem nemrég egy e2e teszteléssel kapcsolatos kérdés miatt. Előtte nem is igazán tudtam, hogy léteznek direkt ilyen célra eszközök (bár a seleniumról tudtam, hogy mire jó).

Sokan úgy vannak vele még mindig, hogy nem érdemes UI-t tesztelni, én is emiatt nem foglalkoztam vele. Valahol olvastam még jópár éve, aztán úgy vagyok vele, hogyha munkát lehet megspórolni, akkor az ember általában bólogatni szokott. Nekem a unit test és az integration test fogalmak, amik tiszták. Ha jól tudom az e2e tesztelés arról szól, hogy végigkövetjük az az utat, amit a felhasználó bejárna, az alkalmazásunk használatakor. Pl megvárja, amíg a böngésző betölti a klienst, kitölti az űrlapot, rákattint a gombra, várja a választ, stb... Valahol el tudom fogadni, hogy ilyesmikre szükség van, sőt talán még alapozni is lehet erre a kliens fejlesztésénél, de nem igazán tudom feloldani a konfliktust a ne teszteljük az UI-t, mert nem éri meg az erőfeszítést szabállyal... A másik, ami totál homály, hogy van rengeteg ilyen tesztelési mód, pl functionality test, acceptance test, meg ki tudja még mik. Elég nehéz követni, ha az ember éppen valami mással foglalkozik. Az én olvasatomban ezek mind integrációs teszt kategóriákban tartoznak, de lehet, hogy rosszul látom.

Ami megint egy érdekes kérdés ezzel kapcsolatban, és amibe nemrég belefutottam, hogy hogyan teszteljünk REST API-t? Elég érdekes dolgok jöttek ki ezzel kapcsolatban is, általában az emberek úgy gondolkodnak a REST API-ról, hogy beteszik a tesztekbe az url-eket statikusan, esetleg templatek formájában, és tesztelik, hogy ezeket curl-el hívva azt a választ kapják e, amit vártak. Valahogy nem állt össze a fejekben, hogy a REST köszönőviszonyban sincs pl a SOAP-pal, amit simán lehetne ilyen módon tesztelni. A REST-nél a jó karbantarthatóság miatt eléggé rákoncentrál arra, hogy a kliens ne tartalmazzon alkalmazás logikát, ne ő maga állítsa elő a controllereket a semmiből, hanem a web service által adott absztrakt controllereket használja erre (lásd HATEOAS principle). Ehhez képest az átlag fejlesztő úgy áll a REST API teszteléshez, hogy ezt az egészet figyelmen kívül hagyja. Nyilván ilyenkor ugyanúgy törékenyek lesznek a tesztek, mint a kliensek egy hagyományos AJAX-os webalkalmazásnál. Nekem az a véleményem, hogy a REST API tesztelésénél hasonlóan kellene eljárnunk, mintha automatizált klienst írnánk. Ugyanúgy linkeket kell követnünk. Ilyen szempontból pl egy seleniumhoz hasonló nem HTML, hanem REST-nél használt hypermedia formátumokra specifikus böngésző, illetve teszt platform baromi jó lenne. A REST-el jelenleg az a legnagyobb probléma, hogy szinte egyáltalán nincsenek eszközeink rá. Jó, a másik legnagyobb probléma, hogy a fejlesztők 99%-a egyáltalán nem is érti, hogy miről van szó, kb ugyanúgy gondolnak rá, mint a SOAP-ra, csak más felülettel kivitelezve. Na de ez már egy másik történet...

Na a hosszas mesélés közepette lemaradt a lényeg. Csak azt akartam megkérdezni, hogy szerinted mikor érdemes ilyen jellegű teszteket használni, illetve, hogy megspórolható e az ilyen jellegű tesztelés? Egyáltalán mit tesztelünk egy selenium teszttel?
9

Főleg intranetes oldalak...

T.G · 2014. Már. 9. (V), 12.34
Főleg intranetes oldalakkal foglalkozok, itt látok benne fantáziát. Egy PR weblap esetén már valószínű nem foglalkoznék ilyennel.

Régebben úgy gondoltam volna, hogy csak az igazán nagy projektek esetén érdemes ezeket az end-to-end teszteket használni, ám most abba bízok, hogyha a teszt írás ideje jelentősen csökken, akkor a kisebb projektek esetén is megtérülhet a használatuk.

Remélem, hogy ugyanúgy lesz majd, ahogy az egységtesztek esetén, az elején még több időt vettek el, ám ma már rutinból írom őket. Az ideálisnak azt tartanám, hogy amikor megyünk az ügyfélhez, akkor előtte legyen már több e2e teszt, amit a prezentáció előtti pillanatokban is tudunk futtatni, hogy nehogy az utolsó pillanatban valamit rosszul töltsük ki, más verzió kerüljön ki stb.
15

Mi nem tudnánk meglenni

dropout · 2014. Már. 25. (K), 22.18
Mi nem tudnánk meglenni selenium grid nélkül.
A test suite 1 órán keresztül fut, és közel sem tesztel mindent. El tudod képzelni, hogy egy ekkora kódbázist különböző verziókon keresztül fejleszteni, featureoket egy évvel ezelőtti verziókba merge-elni vagy egy nagy refaktorálást elvégezni milyen kimerítő folyamat és nehéz mindenre odafigyelni. Ilyenkor nagyon jól jön/jött az e2e testing, bár igazak az aggodalmak azzal kapcsolatban, hogy megéri-e vagy sem. Nekünk megéri, több szempontból is (pl. az alkalmazást unit tesztelhetetlen legacy kódszörnyetegek rohasztják belülről).
REST és SOAP témakörben is nagyon esetfüggő, hogy mi jó megoldás. Mi mindkettőt támogatjuk, jmeter-el egész jó teszteket lehet írni bár nem a szívem csücske.
A szuperagilis trendi startup-nak nyilván más a jó mint annak aki nagyvállalati környezetbe fejleszt évek óta elhagyott, outsource-olt, elmozdíthatatlan kliensekkel körbevéve.
A témához csak annyit, hogy szerintem nem éri meg javascript-el b****kodni. Eclipse, JUnit egy klikk és már nézed is mi baj rendesen debuggolva egy normális IDE-ben, semmi szükség kifforatlan javascript devstack bohóckodásra... bár osztályokat kell írni és az ma már nem trendi (legalábbis itt a weblaboron mwahahaha)
16

Js-ben is lehet szép, jól

inf · 2014. Már. 25. (K), 23.04
Js-ben is lehet szép, jól tesztelt oo kódot írni. A kiforrottság részére még várni kell szerintem sok évet, de én speciel pont ezért szeretem, mert mindig van valami új... Tény, ami tény, mostanában már inkább csak olvasni szeretek róla, mint használni, wiiiiiiiiiii :D :D :D

Én speciel e2e tesztelést inkább az általad említett kódszörnyek refaktorálására használnám első lépésként. off: Már ha elvállalnék ilyen munkákat - már jó ideje nem teszem, és azóta mestere lettem az ilyen jellegű munkákkal zaklató cégek lerázásának. ;-) Mert ugye teszt nélkül nem lehet refaktorálni, és ahol meg nincsenek osztályok, ott e2e teszten kívül nem igazán lehet mást írni...
17

Más a cél

T.G · 2014. Már. 26. (Sze), 11.00
Ez a téma pont arról szólna, hogy komolyabb programozói tudás nélkül is készíthetünk Selenium teszteket. Én magam is az OOP lelkes támogatója, népszerűsítője vagyok, ám ez egy másik projekt. Most az volt a cél, hogy a tesztelők minél könnyebben tudjanak automatizált teszteket készíteni. Azok a tesztelők, akiktől nem elvárás az, hogy "osztályokat kell írni". Nekik teszteseteket kell írniuk, nekünk meg segíteni kell őket, hogy azokat minél egyszerűbben meg tudják oldani.

Egy Java-s projektnél természetesen felesleges lenne JavaScript-et belekeverni a képbe, ám egy nem Java-s projektnél egyáltalán nem biztos, hogy megéri a Java-t belekeverni, főleg, ha van JavaScript-hez értő a csapatban.

Szerintem igenis érdemes minél több segédeszközt megismerni, majd azt használni, amelyik a legjobban beleillik a környezetbe.
18

Most az volt a cél, hogy a

Greg · 2014. Már. 26. (Sze), 12.01
Most az volt a cél, hogy a tesztelők minél könnyebben tudjanak automatizált teszteket készíteni. Azok a tesztelők, akiktől nem elvárás az, hogy "osztályokat kell írni". Nekik teszteseteket kell írniuk, nekünk meg segíteni kell őket, hogy azokat minél egyszerűbben meg tudják oldani.


Ilyen esetekre a cucumber+capybara mondjuk selenium driverrel(bar annal van gyorsabb) megoldas lehet. A teszternek csak a cucumber szintakszist kell megtanulnia, ami eleg egyszeru. Ezutan o meg tudja irni a "feature"-oket a fejleszto meg majd moge rakja a tobbit.
19

Máshol is hallottam már, hogy

inf · 2014. Már. 26. (Sze), 13.01
Máshol is hallottam már, hogy a cucumber jó.
20

Ha tenyleg van olyan szemely

Greg · 2014. Már. 26. (Sze), 13.03
Ha tenyleg van olyan szemely aki nem programozo es megirja a feature-oket akkor valoban hasznos tud lenni. Viszont en meg eddig ilyennel nem talalkoztam :). Ha meg amugy is a programozo irna meg a feature-t, akkor felesleges plusznak tartom a cucumbert.
21

önálló teszt írás

T.G · 2014. Már. 26. (Sze), 14.07
A 20-as hozzászólás fényében a 18-ast nem értem. A Behat-tal kísérleteztem, de nem jutottunk el oda, hogy a tesztelő önállóan írjon teszteket, amihez nem volt szükség komoly "aládolgozásra".

Ezzel szemben a Nightwatch.js -sel pont azt sikerült elérni, hogy minimális tanulás után (CSS szelektorok ismerete a legtöbb tesztelőnél megvan) önállóan bárki tud klikkelgetős teszteket gyártani.

Én a BDD-re úgy tekintek, mint előre megírt specifikációra, amit akár az ügyféllel is leegyeztetünk. Ellenben a Selenium tesztek utólag készülnek, ügyfél nélkül, kizárólag belső ellenőrzésre, emiatt nem szükséges a laikusok számára az olvashatóság, illetve minimális scriptelés megengedett.
22

Egy teszter meg tudja tanulni

Greg · 2014. Már. 26. (Sze), 14.55
Egy teszter meg tudja tanulni a cucumber-t olyan szinten hogy sajat maga megirja a teszteket, igy nem kell aladolgozni. Amivel probaljak eladni, az az, hogy a feature-ek akar az ugyfel is megirhatna(ez azert tulzas :)). En dolgoztam olyan csapatban ahol a terv az volt, hogy a project manager megirja majd a feature-oket(mert o egyezteti az ugyfellel hogy mire van szukseg), a programozo meg a featureokhoz a step definition-oket. Aztan a vege az lett, hogy a feature-t is mi programozok irtuk, hogy szerintem felesleges plusz melo volt a cucumber.
Igy nez ki egy feature egyebkent:

Feature: Addition
  In order to avoid silly mistakes
  As a math idiot 
  I want to be told the sum of two numbers

  Scenario Outline: Add two numbers
    Given I have entered <input_1> into the calculator
    And I have entered <input_2> into the calculator
    When I press <button>
    Then the result should be <output> on the screen

  Examples:
    | input_1 | input_2 | button | output |
    | 20      | 30      | add    | 50     |
    | 2       | 5       | add    | 7      |
    | 0       | 40      | add    | 40     |
De akar magyarul is meg lehet irni: https://github.com/cucumber/cucumber/blob/master/examples/i18n/hu/features/osszeadas.feature
Mondjuk a nightwatch szintakszisa inkabb a capybarahoz hasonlit es az tenyleg elony, hogy a js egy elterjedt nyelv, igy relative konnyu betani ra valakit.
23

Ja elméletben jó terv lenne,

inf · 2014. Már. 26. (Sze), 15.01
Ja elméletben jó terv lenne, én is erre gondoltam, de a gyakorlatban ott bukik el, hogy azt várjátok a menedzserektől, hogy dolgozzanak... :D esélytelen...
24

középút

T.G · 2014. Már. 26. (Sze), 15.56
Félreértés ne essék, én nagyon jó dolognak tartom a BDD-t. Ám ennek ellenére csak korlátozottan használom. Nem tudom, hogy a Behat mennyivel kevesebb, mint a Cucumber, gondolom a lényeg azért ugyanaz. Ami engem elsőre zavart, hogy túl nagy energiát elvett a mintaillesztések gyártása.

Tehát egyik oldalon van a gherkin féle nagyon szépen olvasható leírás, ám minden egyes sorához kell egy-egy mintaillesztést gyártani. Másik oldalon van a Java-ban írt Selenium tesztek, amihez meg komoly programozói ismeretek szükségesek. Véleményem szerint valahol félúton, kompromisszumos megoldásként jött a Nightwatch.js. Programozói ismeret nélkül is könnyen megtanulható, ám utána gyorsan sorozatban gyárthatunk teszteket. (amúgy biztos vagyok benne, hogy még számtalan hasonló megoldás van, én elsőre ezzel találkoztam, megtetszett, bevált, de biztos van más is)

Később lehet, hogy változni fog a véleményem, de ma nem látom értelmét olyan tesztet készíteni BDD-vel, amit legalább egyszer meg nem mutatnék az ügyfélnek. Ám valószínűleg hülyét is kapna, ha mutatnék neki öt majdnem tök ugyanolyan tesztet, amelyben azt vizsgálom, hogy ha rossz sorrendben hajtom végre a műveleteket, akkor a különféle hibaüzenetek megadják, hogy mit csinálok rosszul. Az ilyen típusú tesztek nyugodtan mehetnek belső használatra, ahol nem szükséges a gherkin féle olvashatóság.
25

Az ügyfelet szerintem inkább

inf · 2014. Már. 26. (Sze), 17.23
Az ügyfelet szerintem inkább az érdekli, hogy ha lerakod a szoftver elé, akkor tudja használni, és nem az, hogy milyen szuperül működnek a tesztek, vagy hogy teljesen bug mentes a szoftver... Én néha egy kicsit erőltetettnek érzem ezt a tökéletes kódra törekvést.
4

Szerintem mivel mindegyik a

inf · 2014. Már. 9. (V), 09.57
Szerintem mivel mindegyik a Selenium-ot hajtja meg, így komoly különbségek a működésben biztosan nem lesznek. Ami engem megfogott a Nightwatch.js-ben, hogy náluk az egyszerű szintaxis különösen fontos volt. Nem kell olyanokat leírni, hogy: driver.findElement(webdriver.By.name('btnG')).click(); Elegendő csak annyi, hogy client.click('button[name=btnG]');


Azért nem egyszerű egy ilyen felületet összehozni. Nézegettem a protractort, illetve az alatt lévő webdriver-t, és csurig van aszinkron kóddal, promise-ekkel, stb... A protractor próbálja valahogy elfedni ezt a jellegét a dolognak, többé kevésbé sikerrel, pl a jasmine köré tettek egy async wrapper-t, ami elfedi, hogy ténylegesen aszinkron tesztekről és promise-ekről van szó egy-egy expect hívásakor. Ettől függetlenül ja, tényleg nem tökéletes, amit csináltak, nem is igazán értettem, hogy miért jó ennyire túlbonyolítani valamit. Megnéztem a nightwatch-ot, és körülbelül én is ilyennek képzeltem el egy használható teszt rendszert.

Újabb kérdés, hogy mennyivel érdemesebb a seleniumot használni, mint mondjuk egy olyan http klienst, ami eleve automatizált kérésekre lett tervezve, pl phantomjs. karma-phantomjs-launcher?

off: ma úgy látszik ilyen bőbeszédű vagyok...
8

Phantom.js

T.G · 2014. Már. 9. (V), 12.19
A Selenium-ban nekem az tetszik, hogy az valóban a böngészőben tesztel, Phantom.js-ben például IE hibákat biztosan nem tudnánk előhozni. Bár mondom ezt úgy, hogy igazából a Phantom.js-sel még nem igazán foglalkoztam.
10

Phantom.js-ben például IE

inf · 2014. Már. 10. (H), 00.59
Phantom.js-ben például IE hibákat biztosan nem tudnánk előhozni. Bár mondom ezt úgy, hogy igazából a Phantom.js-sel még nem igazán foglalkoztam.


Én ezeket a különbségeket inkább külső keretrendszerekre bíznám, pl jquery... Egyébként én sem foglalkoztam még phantomjs-el, de szeretek tisztában lenni a lehetőségeimmel. Úgy nézem, hogy a selenium ugyanúgy támogatja a phantomjs-t is, szóval ha a sebesség szempont a teszteknél, akkor fejlesztéshez érdemesebb phantomjs-el használni a teszteket, és csak a végén debuggolni a böngészők közti különbségekből adódó hibákat, már ha vannak ilyenek...
5

bugdemó?

zzrek · 2014. Már. 9. (V), 10.17
Nem volt még szerencsém az ilyen eszközökhöz, ezért laikusként kérdezem: a Selenium és például a Nightwatch arra is alkalmas, hogy ha egy hibára akadtam valaki más rendszerében, akkor ezt demózhatom vele? Mert akkor még valamilyen bugzilla scriptelésre is jó lenne akár.
6

Teljes mértékben...

inf · 2014. Már. 9. (V), 10.36
Teljes mértékben... Máris plusz egy pont arra, hogy miért érdemes ismerni ezeket az eszközöket...
7

Demózás

T.G · 2014. Már. 9. (V), 12.19
Én most úgy gondolom, hogy ezeket a teszteket nem is kizárólag a programozóknak kellene írniuk, a bugdemóhoz képest egy lépéssel még továbbmennék, azon gondolkodom, hogy a valódi demózáshoz is használható lenne a Selenium tesztelés. Számtalan alkalom volt, hogy valahol a bemutató félresiklott, ám ha előre fixálva lennének a lépések, akkor nem fordulhatna elő, hogy a prezentáció alkalmával mellé klikkelnek.
11

Jó, de hogyan oldható meg a

inf · 2014. Már. 10. (H), 01.01
Jó, de hogyan oldható meg a tesztek megjelenítése?

Van a selenium esetében olyan opció, hogy mutassa, hogy mi folyik a böngészőben tesztelés közben, esetleg még animációs is csináljon róla mondjuk egy mesterséges kurzorral?
12

külön ablak

T.G · 2014. Már. 10. (H), 08.49
Ha a konzolon elindítod a tesztet, akkor egy külön ablakban a Selenium megnyitja a böngészőt és mindent látsz. Még akár bele is kattinthatsz. Most azzal kísérletezek, hogy van olyan utasítás, hogy várjon, míg eltűnik valami, prezentáció során kiteszek egy panelt, arra egy tovább gombot. Amikor az megjelenik, akkor tetszőleges ideig lehet a felületnél beszélgetni, majd a tovább gombra eltűnik a panel, és a Selenium script fut tovább.
A kurzor mozgatása már más kérdés, ott csak egy mesterséges kurzor lehetne. Van olyan, hogy moveToElement utasítás, ez működhet.
13

Saucelabs

MadBence · 2014. Már. 10. (H), 09.29
https://saucelabs.com/

A tesztekről screenshotok, illetve videó is készül (és ahogy nézem, Seleniumot használ), szóval mindenképpen megoldható.
14

Ja így van, karmának van

inf · 2014. Már. 10. (H), 09.38
Ja így van, karmának van pluginje hozzá, pont ilyen célokra használják. Talán egy hete került szóba, de már az én fejem sem tart meg mindent...