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

  • Jim-Y
    veterán

    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 :P

    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.

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