Dotaz: testovani

[pulec]

Ahoj, snazim nejak rozvrhnout strukturu aplikace a zasekl jsem se na testovani. Zdrojaky aplikace mam v adresari app a unit testy v adresari test. Problem, na ktery jsem narazil je ten, ze neumim poradne zaradit testy, ktere testuji live system. Nejsem si jist jak se tomu rika - integracni testy / funkcni testy?

Jak postupuju. Napisu si tridu napr. ktera vola REST api, ktere dela nejake operace a vraci JSON data. Tu tridu si vyzkousim tak, ze napisu metodu ve, ktere se vytvori instance tridy, zavola se metoda, ktera precte data, a pak se vypisou do console. Takovych prikladku mam nekolik a resim co s nimi. Nechci je zahodit, ale nechci je ani davat do unit testu, protoze pracuji s externim system a v mnoha pripadech nestahuji jen data, ale ho i meni.

Dali byste takove prikladky dat do adresare "test/examples", "functionalTests", "integrationTests" nebo nejakeho jineho?

Kdybych mockoval metody, pak by se testoval jen interface, ale ja potrebuju proste videt vypisy v konzoli, ze ty realne data a ze to fakt spravne komunikuje a pracuje s externim systemem, coz je pro me uzitecnejsi nez unit testy. Jak s tim ale nalozit?

Dale jsem premyslel, jak zamezit tomu, aby nekdo pak takovy prikladek (test) nechtene spustil a vykonal v externim systemu nejakou operaci. Jestli je dobre treba volani metody zakomentoval a az ten kdo to bude zkouset si bude jisty ze opravdu vi co dela, tak ji odkomentuje a spusti. To je vlastne taky duvod proc uvazuju ze takovy prikladek neni test a taky proto, ze netestuje vystup, ale jen loguje do console.

Diky za prip. napady... pulec

Odpovědi

[debug]

Ahoj, snazim nejak rozvrhnout strukturu aplikace a zasekl jsem se na testovani. Zdrojaky aplikace mam v adresari app a unit testy v adresari test. Problem, na ktery jsem narazil je ten, ze neumim poradne zaradit testy, ktere testuji live system. Nejsem si jist jak se tomu rika - integracni testy / funkcni testy?

Jak postupuju. Napisu si tridu napr. ktera vola REST api, ktere dela nejake operace a vraci JSON data. Tu tridu si vyzkousim tak, ze napisu metodu ve, ktere se vytvori instance tridy, zavola se metoda, ktera precte data, a pak se vypisou do console. Takovych prikladku mam nekolik a resim co s nimi. Nechci je zahodit, ale nechci je ani davat do unit testu, protoze pracuji s externim system a v mnoha pripadech nestahuji jen data, ale ho i meni.

Dali byste takove prikladky dat do adresare "test/examples", "functionalTests", "integrationTests" nebo nejakeho jineho?

Kdybych mockoval metody, pak by se testoval jen interface, ale ja potrebuju proste videt vypisy v konzoli, ze ty realne data a ze to fakt spravne komunikuje a pracuje s externim systemem, coz je pro me uzitecnejsi nez unit testy. Jak s tim ale nalozit?

--debug

Dale jsem premyslel, jak zamezit tomu, aby nekdo pak takovy prikladek (test) nechtene spustil a vykonal v externim systemu nejakou operaci. Jestli je dobre treba volani metody zakomentoval a az ten kdo to bude zkouset si bude jisty ze opravdu vi co dela, tak ji odkomentuje a spusti. To je vlastne taky duvod proc uvazuju ze takovy prikladek neni test a taky proto, ze netestuje vystup, ale jen loguje do console.

Diky za prip. napady... pulec

Co tak pred spustenim testov zaarchivovat. ... Napisat simple README. ... Testovaci vs produkcny stroj

[Kit]

Debug je něco jiného než testy.

Archivace sice má význam, ale určitě ne k tomuto účelu.

[pulec]

Pridat "--debug" parametr? Testiky nejsou soucasti aplikace, jsou bokem (zatim v adresari "test"), ale museji byt dostupne pri vyvoji, jako podpurna vec, tzn. stejna repository. Stejne jako se spousti pri vyvoji testy, tak se obcas spusti i ty "testy".

Ty prikladky komunikace s externim systemem s vypisem do konzole jsou dobre pro programatora, protoze vidi jak pracovat s danou tridou. Jake muze volat metody, jaky je styl komunikace, jaka je posloupnost volani. Pri spusteni i primo vidi co vraci externi system. Muze menit hodnoty a menit tak navratove zpravy apod. Ale asi to teda neni test, ale jen nejaky ukazkovy skriptik. Nevim v testovani se moc nevyznam. A byl bych rad kdybyste nekdo napsal jak to delate a jak se tomu vlastne rika.

V pripade, ze by ty prikladky byly napsane jako testy - tzn. IDE by je treba mohlo spustit vsechny najednou, coz je nebezpecne - by se tomu muselo nejak zabranit. Treba tim zakomentovanim. Kdyby se to zabalilo, tak by to byl opruz neco vyvijet, rozbalit cas kodu, spustit, neco upravit, zabalit atd.

[Kit]

Jednotkové testy se dělají na vývojářském stroji, stejně tak i integrační. To už zřejmě máš podchyceno.

Vypadá to, že chceš dělat testy systémové a akceptační, které se dělají na produkčním stroji. Často se píší v jiném jazyce a tak nevadí, když sdílí stejný adresář test/. Pokud si to chceš dát do nějakého podadresáře, je to tvá záležitost.

Mockovat budeš muset především datové zdroje, abys vyzkoušel hraniční stavy a nerozbil sis přitom ostrá data. Abys tyto testy uchránil před nenechavci, udělej si na to testovacího uživatele, kterému se po přihlášení namockují jiné datové zdroje (resp. budou mockovány operace zápisu) a výstupní šablony s podrobným hlášením stavů a chyb.

[pulec]

Zkusim to popsat jeste jinak.

Vyvojar ma za ukol napsat komunikaci s bankovnim systemem. Precte si dokumentaci pouziti API. Napise tridu, ktera obsahuje metody jako { getBalance, withdraw, deposit }. Musi nejak otestovat jestli opravdu funguje. Nemuze mockovat, protoze nevim co externi system (banka) vraci. Napise si tedy maly testovaci priklad:

bank = Bank()
balance = bank.getBalance()
print balance

Tento priklad ale neobsahuje zadne porovnani vysledku, co ma externi system vratit. Chybi zde assert. Tento prikladek neni soucasti vysledne aplikace, jen umozni vyvinout spravne danou tridu. Taky je skoda, aby ji programator zahodil, az bude mit napsanou komunikaci spravne, protoze kdyz externi system (banka) udela update v API, tak programator muze pomoci tohoto prikladku, ktery si znovu spusti zjistit co se zmenilo a overit si, ze to tak opravdu je a dokumentace nelze atd.

Takze je dobre takove veci nekde uchovat - v adresari "test" nebo tedy "test/systemTests"?

Kdyz se z takoveho prilladku udela test:

test():
  bank = Bank()
  balance = bank.getBalance()
  print balance

tak vyvojove prostredi ho bude moci spoustet. Ale to zase neni potreba, protoze neni co testovat - samotny test neobsahuje assert metodu, podle ktere by test framework poznal, jestli test probehl spravne nebo ne. Takze by to byl zase zbytecny "test". A v pripade, kdyby tento "test" obsahoval metody withdraw nebo deposit, by se mohlo stat, ze by nekdo prisel o penize. To je taky nechtene.

Kdyz ale prijde programator a bude potrebovat upravit onu tridu, kvuli toho, ze banka pridala novou metodu do sveho api (tzn. neni jeste nikde pokryta v testech), tak muze pouzit onen prikladek a otestovat si banku, co mu vraci za vysledky. Takze se musi nejak dostat k onomu prikladku.

Pujde tedy ve zdrojacich do adresare "test/systemTests" ? Nebo do neceho pojmenovaneho jako priklady pouziti? "test/examplesOfUse" ? Nebo je toto systemovy test ci integracni test? Jedna se totiz vpodstate o vyzkouseni si casti aplikace s realnym systemem - ale pravdepodobne jen pro programatory.

Aby to byl skutecny test musel by mockovat externi system, predhazovat nejake data a testovat vystup:

test():
  bank = MockedBank()
  balance = bank.getBalance()
  print balance
  assert(balance == 1000)

Jenze pak se testuje samotna trida bank. Kdyz pak prijde programator dopsat novou fnukcionalitu, tak sice vidi jak to funguje, ale nevi co realna banka vraci. Musi si napsat na zkousku realnou komunikaci, upravit test a zvuj realny test smazat.

No a ja se snazim prijit na to co je to vlastne ten realny test/priklad a kde ho zaradit v ramci zdrojaku.

[OldFrog {Ondra Nemecek}]

Podle mě bylo víceméně zodpovězeno už tímto:

Vypadá to, že chceš dělat testy systémové a akceptační, které se dělají na produkčním stroji. Často se píší v jiném jazyce a tak nevadí, když sdílí stejný adresář test/. Pokud si to chceš dát do nějakého podadresáře, je to tvá záležitost.

Pokud nemůžeš při testu měnit ostrá data (= nemůžeš skoro nikdy) a chceš současně otestovat změnu dat skoro jako v ostrém provozu (= chceš skoro vždy), budeš potřebovat nějakou testovací instanci těch ostrých služeb. To už je pak na dohodě s provozovatelem, zda ji zřídí. Nemusí jít vždy o celou testovací instanci, může jít o spuštění pod speciálním testovacím uživatelem apod.

V konfiguraci testů pak uvedeš spojení na tu testovací instanci a nemusíš ji mockovat. A současně nevadí, když to někdo spustí omylem, maximálně test selže protože testovací instance není dostupná.