Jak přistoupit k integračním testům?

[petersveter]

Riesim integracne/e2e testy webovej aplikacie, cize testovanie aplikacie so stejtom(db/cache...). Mam cez 170 handlerov a rozmyslam ako k tomu pristupit.

Davnejsie sme v praci riesili integracne testy so Selenium a proste automatizovana klikaca cez web. To nastastie teraz robit nemusim a mozem testovat priamo kod pretoze mam hexagonalnu/"cibulovu" architekturu takze mozem priamo volat kod a obyst tak http vrstvu. Vtedy sme riesili len najdolezitejsie cesty, volali sme to "playbook" a bol to "pribeh", kedy uzivatel isiel z A do B a cela cesta bol vlastne test. Preklikat sa cez web a formulare zo stavu A do stavu B(napriklad prejst objednavkovy proces -> produkt, kosik, platba..).

Ja ale chcem otestovat vsetky handleri, takze rozmyslam ze ako k tomu pristupit. Ci ist cestou, ze jeden handler = 1 test/playbook, alebo ci mam spravit jeden test/playbook a don zaclenit viacero handlerov?

Hlavny problem je ze tu vlastne vecsina handlerov zavisi na predoslom stave, takze na inych handleroch/testoch.

Napriklad registracia uzivatel je 1. odoslanie zakladnych udajov, 2. odoslanie emailu, 3. uzivatel potvrdi email cim 4. vytvori ucet v systeme. Prakticky sa teda testuju dva handleri a jedna automatizovana uloha(odoslanie emailu). A ja teda mozem otestovat odoslanie uzivatelskych dat(validny email? vyplnene meno?), lenze vytvorenie uctu uz vyzaduje ten predosly stav, takze vlastne testujem dva handleri a nie jeden. A teda ma zmysel mat dva testy?

Tiez mam problem ze nechcem otestovat len zmeny stejtu/workflow, lebo to je spravanie aplikacie(tie spominane playbooky), ale chcem aj otestovat validaciu handlerov. Napriklad "existuje uz tento email?" je validacia ktora pracuje so stavom ale tiez "je toto validny email?" uz pracuje len na urovni kodu a teda hned tu mam dve rozne validacie, ktore su v hre len pre jeden handler.

A potom tu moze byt este mnoho dalsich, ako ze "email uz bol odoslany", "je dnes utorok?", "uzivatel nevlastni tento obsah", "uzivatel ma pravo vytvorit tento obsah" a podobne. A tie handleri su viac a viac komplexnejsie ak ide o validaciu vstupnych dat, a hlavne v kontexte stavu aplikacie(db).

Takze proste neviem ako k tomu spravne pristupit. Lebo chcem otestovat, ze apliakcia funguje spravne ale aj ze handleri validuju stav tiez spravne.

Zaujimalo by ma ako k integracnym testom pristupujete bezne vy a ci mate nejake tipy? Toto je asi druh testovania ktory sa uplne najviac flaka, takze niet moc kde cerpat informacie z prvej ruky.

[Reklama]

[alex6bbc]

stejne musis projit predesle stavy, aby ses dostal k otestovani nasledneho stavu. takze klidne vyuzij uspesne probehle predesle testovaci kroky.

[RDa]

Tak mas dve varianty - delat to skriptovane, podle scenaru, nebo na to pustit stado opic. Zvol tu, ktera bude levnejsi, ne?

[Ink]

Jednoznačně bych šel cestou delších cestiček, předpokládám, že stejně pro většinu akcí musíš mít uživatele v přihlášeném stavu, tedy držet si session v rámci nějaké akce, nebo ne? Tzn. minimálně "uživatel se přihlásí" a něco udělá. Jinak si myslím, že je celkem jedno, kolik budeš mít "playbooků", otázkou je, jak ten systém bude reportovat výsledky. Používáš nějaký standardní framework? Umožňuje pro každý handler reportovat samostatně výsledek? Reportuje to pro každý "playbook"?Jak probíhá vyhodnocování výsledku? Máš seznam testovaných akcí, aby sis ověřil, že někde nemáš vynechaný test? Pokud máš tohle vyřešené, je asi jedno, jestli máš jeden "playbook" nebo 300. Prostě si projdeš checklist po dokončení testů a zpracuješ výsledek.

[luvar]

Ono je otazka, preco ides robit e2e testy. Co je cielom. Podla ISTQB (testerske certifikacia vpodstate) by si mal mat nejaku biznis oblast (tlac faktur, spracovanie daní,...) a tato oblast obsahuje nejake use-case a tieto usecase maju nejake TC (tesc case-y). Nasledne exekuujes mnozinu TC a na zaklade toho vies, ktora oblast tvojeho sw, je ako rizikova (podla pokrytia testami a podla uspesnosti exekucie).

Primarnym cielom e2e testov by nemalo byt preverenie "vsetkeho". To mas robit v unit testoch (overenie, ze validacie su naprogramovane spravne). V e2e mas overit, ze validacie su na danom screen-e pritomne a aktivne a ze sa korektne zobrazuju. A to sme pri tom, ze vlastne ty chces robit system test (testujes backend a nie end to end, lebo nechces ist cez browser).

Long story short:

• na kontrolu validacii pouzi PBT (property based testing); v java svete napriklad https://jqwik.net/
• v UAT (user acceptance tests), alebo system tests, ktore robis, sprav v kazdej oblasti niekolko dlhsich playbookov a snaz sa asertovat "naraz"

Pod asertovanim naraz myslim, ze test nepadne pri prvom chybnom aserte, ale vypise vsetky chybne aserty (assertAll v niektorych frameworkoch)

Pre dlhe letne dni odporucam citanie https://atsqa.org/educational-resources (primarne by malo stacit https://atsqa.org/assets/documents/ISTQB_CTFL_Syllabus-v4.0.pdf pre uvedenie do obrazu a pojmov).

[Reklama]

[petersveter]

Tak som dospel k tomu, ze request validovat mozem ako unit test. Co sa stavu tyka, musim prerobit nejaky kod a zbavit sa privatnych funkcii a poli a mozem tak vlastne "mockupnut" aplikaciu, respektive jej casti, ktore potrebujem pre test konkretneho handleru. Cize napriklad ak pre validaciu registracie uzivatela volam vnutorne "je email volny?", tak mozem tuto metodu pretazit a vratit vysledok ktory potrebujem pre test, takze sa ta metoda, alebo iny handler, realne nevola. Cize je to akoby unit testovanie ale so stejtom.

[petersveter]

Tak som sa s tym hral cely den. Prerobil som kod na nieco taketo(Go kod):

Kód: [Vybrat]

// predtym
func (m *Manager) CreateUser(ctx context.Context, req CreateUserRequest) (CreateUserResponse error)

// potom
type CreateUserManager interface {
... methody ktore boli predtym volane priamo z Manager
}

func CreateUserHandler(ctx context.Context, m CreateUserManager, req CreateUserRequest) (CreateUserResponse, error)

func (m *Manager) CreateUser(ctx context.Context, req CreateUserRequest) (CreateUserResponse) {
  return CreateUserHandler(ctx, m, req)
}

co mi umoznilo prakticky vytvorit unit testy. A spravnost stavu sa da potom taktiez cez kvazi unit test overit tym ze sa len overia udaje ktore sa zapisuju do db cez prislusne metody a teda netreba to overovat v kazdom handleri. Problem vsak je ze niektore handleri nie su naozaj na 5 riadkov a proste sa tam deje toho prilis vela aby to bolo takto testovatelne. A teda jedine co mi z tohoto vyplyva je ze jediny zmysel ma testovat tie spominane playbooky a teda nejaky pribeh uzivatela ktory idez bodu A do bodu B a prakticky nema ani vyznam snazit sa spustit nevalidny stav ale naopak len ist spravnou cestou a teda bez problemov sa snazit dostat do ciela(ie. vytvorit clanok). Akekolvek validacne veci, ci uz v kode alebo stejte, proste nema zmysel validovat lebo tie kombinacie su privelke a prilis sa to vetvi na to aby to bolo nejak realne testovatelne.

Takze to je zatial moj zaver k tomuto. Nemozem povedat ze som s tym spokojny ale aktualne mi nepride ze sa da nieco viac vymysliet, co by bolo prakticky realizovatelne.

[snugar_i]

To zní jako že začínáš objevovat Dependency Injection

[petersveter]

To zní jako že začínáš objevovat Dependency Injection

Tak som zvyknuty pisat nejakym stylom a v tomto pripade to sposobilo ze kod nie je funkcne testovatelny.
Pocas vikendu som na koniec prerobil vsetky handleri takze uz skoro vsetka funkcionalita sa deje iba vramci dodanych argumentov. Problem bol primarne v tom, ze tie handleri som mal nalinkovane na hlavny objekt(predstavte si http server objekt/struct napriklad, ktory ma vsetky zavyslosti interne v sebe a handleri pre http routy len volaju vnutorne veci co potrebuju), takze som nemohol kontrolovat ktore metody co vratia. Takze to som poriesil ako som pisal hore a kod uz sa da testovat.

Popravde malo kedy sa clovek stretne s testami(jasne ze zalezi kde v IT clovek robi a s cim sa stretava), a uz duplom nie s niecim viac nez su unit testy. Takze tak sa vytvaraju zle naviky, respektie ani nie zle ale proste ked pride na lamanie chleba, vtedy vznikne problem. Ale tym ze to nie je caste tak sa to proste ignoruje lebo to v bezej praxi problem nie je. It is what it is.

V kazdom pripade, aktualne mozem riesit integracne/funkcne testovanie, ale toho kodu je privela a dospel som k tomu ze to aktualne nema zmysel moc. Zmenil som pozornost na akceptacne/e2e testy kedy robim s db a pracujem s uzivatelom/akterom ktory vykonava rozne akcie.

Akurat tam zase som si neni isty ako k tomu uplne pristupit, kedze s tym nemam prax moc. V principe mam v systeme 5 typov uzivatelov a neviem ze ako ich spravne testovat, lebo v roznych krokoch musi byt medzi nimi interakcia(napriklad userA poziada adminaB o nieco, adminB musi vykonat nejaku akciu aby userA mohol potom nieco robit, tak podobne).

Neviem ci mam napisat test tak ze sa sustredim len na jedneho uzivatela a ked treba dalsieho tak to je ok, alebo mam proste uzivatelov zoskupit a proste tak nejak otestovat vsetky kroky? Alebo ci mam testovat uspesnu cestu alebo ci testovat aj nieco co by nemalo prejst(absencia objektu alebo opravnenia) a td. Co si pametam z akceptacnych testov tak proste sa riesi len uspesna cesta, cize "mozem si objednat produkt a zaplatit zan kartou VISA?" a vtedy je jasne o co ide. Ale uz sa netestuje ci mozem platit aj inou kartou alebo ci dopravna metoda podporuje vobec platbu kartou. A proste je to trosku chaos potom zistit ze co sa vlastne ma testovat.