Új hozzászólás Aktív témák

• Jim-Y veterán

  #5173

  #5170 dqdb

  2015-04-13 10:08:36

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Jim-Y

  veterán

  #5170 dqdb

  #5170 dqdb

  adott esetben elég problémás bugról van szó egy éles projektnél, akkor azt nem jó ellökdösni, hogy majd megcsinálom, mert akkor elfelejtődhet
  Nem, ilyen nem fordul elő sosem, mert ugyebár mindenre van egy XKCD testcase

  És erről jutott eszembe: valaki belemélyedt már jobban a kliensoldali automatizált tesztelésbe? Vajon mekkora beletanulási ideje lehet egy Jasmine+PhantomJS párosnak? A többi rész után szeretném a webes UI tesztelését is automatizálni, a kollégákkal ellentétben a Jenkins mindig ráér foglalkozni vele, és alaposan dolgozik

  Szia, mi -sajnos- nem hasznalunk PhantomJS-t, pedig en szemely szerint egy headless approach-nak jobban orulnek, mint amit most a Karma nyujt, hogy megnyit egy bongeszo ablakot teljesen feleslegesen :/ Na mindegy, a lenyeg, hogy szerintem egy Jasmine elsajatitas nem tart tovabb par oranal. Igazabol semmi extra nincs benne, kell szerezni egy Jasmine cheat-sheet-et es akkor rogton hatekony munkat lehet vegezni benne. E2E tesztekben nincs nagy tapasztalatom, bar szerintem jo lenne ha lenne ra lehetosegunk, egy gondot latok ezekkel a tesztekkel, hogy

  ad1: kell hozza egy habitus, a projekt team reszerol, hogy mindenkinek alap legyen, hogy a task egyben azt is tartalmazza, hogy teszteket kell csinalni
  ad2: hogy ki legyen kenyszeritve a teszt ellenorzes-iras, peldaul git/svn precommit hookokkal vagy hasonlokkal.

  Nalunk most azzal van szivas, hogy hogy lehetne normalisan mockolni a tesztekben a require dependenciakat. Es nem is az elsoszamuakat, mert azzal nincs gond, hanem ha en fuggok egy A modultol, ami fugg egy B modultol, akkor hogy tudom a tesztben mockolni a B modult. Erre azert van szukseg, mert sajnos az app az elejetol kezdve rosszul lett felepitve es nem alakalmas a tesztelesre. Mert pl a B modul egybol bootstrapeli az alkalmazast ami nyilvan nem jo Ezert kene mockolni.

• martonx veterán

  #5172

  #5170 dqdb

  2015-04-13 08:27:01

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  martonx

  veterán

  #5170 dqdb

  #5170 dqdb

  adott esetben elég problémás bugról van szó egy éles projektnél, akkor azt nem jó ellökdösni, hogy majd megcsinálom, mert akkor elfelejtődhet
  Nem, ilyen nem fordul elő sosem, mert ugyebár mindenre van egy XKCD testcase

  És erről jutott eszembe: valaki belemélyedt már jobban a kliensoldali automatizált tesztelésbe? Vajon mekkora beletanulási ideje lehet egy Jasmine+PhantomJS párosnak? A többi rész után szeretném a webes UI tesztelését is automatizálni, a kollégákkal ellentétben a Jenkins mindig ráér foglalkozni vele, és alaposan dolgozik

  Beletanulási ideje kb. nulla (na jó, egy nap mondjuk).
  Más kérdés, hogy akkor már gondolom van deploy automatizmusotok, CI rendszeretek, amibe beilleszteni a cuccot, nem feltétlenül tirivális.

  Egyébként nem vagyok nagy híve a kliens oldali automatizált tesztelésnek. Ha csak egy class, vagy id megváltozik, máris törnek a tesztek. Ilyen szerver oldalon sokkal ritkább, és jellemzően olyankor jogosan törnek el a tesztek. Ráadásul a kliens oldali logikák általában nagyságrendekkel egyszerűbbek, mint a szerver oldaliak.
  Szóval nálunk ha piros a kliens oldali teszt, akkor 80%, hogy a teszt hibás. Ráadásul olyat tesztelni, hogy ha A gombot megnyomom, akkor átmegyek a B oldalra, hááát ezekben azért túl nagy hibák amúgy se tudnak előjönni, s akkor is inkább szerver oldali hiba okozza.

Új hozzászólás Aktív témák