Ú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

  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

  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