Automatizovano testiranje

Šta učimo ovog semestra

Petnaest sedmica: svaka ima tri časa teorije i tri časa praktične nastave. Danas: poglavlje 4 (Sedmica 4, označeno). Isti primjer kroz knjigu: DeliveryApp, narudžba N-1001.

Šta učimo ovog semestra

Literatura

1. J. Popović: Priručnik za test inženjere, CET i Računarski fakultet, Beograd, 2023.
2. Rakić-Skoković: Priručnik za testiranje softvera, Fakultet tehničkih nauka, Novi Sad, 2013.
3. G. J. Myers: The Art of Software Testing, 2. izdanje, John Wiley & Sons, 2004.
4. A. P. Mathur: Foundations of Software Testing, Addison-Wesley Professional, 2008.

Priča za početak

Netflix je oko 2010. godine prebacio svoj sistem u oblak, na hiljade iznajmljenih servera. Inženjeri su znali da će u takvom sistemu neki server svakog dana negdje otkazati: tako rade veliki računski centri. Pitanje nije bilo „hoće li otkazati”, nego „hoće li ostatak sistema to izdržati”. Umjesto da čekaju da kvar dođe sam, u nedjelju u tri ujutro, napravili su program sa šaljivim imenom Chaos Monkey („majmun haosa”). Program je, u radnom vremenu, dok su inženjeri bili tu, nasumično gasio servere u stvarnom sistemu.

Ako bi gašenje jednog servera nešto pokvarilo, tim bi to vidio odmah, popravio, i sistem bi postao otporniji. Kasnije su napravili cijelu „vojsku majmuna” (Simian Army) za druge vrste kvarova, a Chaos Monkey su 2012. objavili kao otvoreni kod, da ga koriste i drugi. Ideja je jednostavna i moćna: ono što se može provjeriti automatski, provjerava se stalno, a ne jednom pred isporuku. Čovjek ne bi mogao svaki dan ručno gasiti servere i bilježiti šta se desilo; program može, bez umora, iznova i iznova.

Zašto ovo poglavlje

U poglavlju 3 testirali smo web stranicu DeliveryApp rukom: izvršili smo osam test slučajeva i istraživali prvu verziju. To je dobro za nove funkcije i upotrebljivost, ali ima granicu. Ako svaki put kad programer promijeni kod treba ručno izvršiti 40 testova, tim će ih brzo prestati izvršavati. Ovo poglavlje uči automatizovano testiranje: program koji testira program. Prvo vidimo kada se automatizacija isplati, i to izračunamo. Zatim piramidu testova i vrste alata. Na kraju pišemo prvi automatski test, prvo samim Pythonom, pa u alatu pytest, i pokrećemo ga nad obje verzije DeliveryApp. Na praktičnoj nastavi tabela iz poglavlja 1 postaje skup automatskih testova koji se izvrši za manje od sekunde.

Riječi ovog poglavlja (1/2)

• Automatizovan test – program koji pokrene dio sistema, uporedi rezultat s očekivanim i javi da li je prošao.
• Okvir za testiranje (test framework) – alat koji pronalazi, pokreće i izvještava o testovima (npr. pytest, JUnit).
• Tvrdnja (assertion) – naredba koja provjerava da je nešto tačno, i javlja grešku ako nije (u Pythonu assert).
• Isplativost automatizacije – trenutak od kojeg automatski test štedi više vremena nego što je koštao.
• Piramida testova – mnogo brzih jediničnih testova u podnožju, manje integracionih, malo sporih testova kroz ekran na vrhu.
• Nestabilan test (flaky test) – test koji ponekad prolazi, a ponekad pada, bez izmjene koda.

Riječi ovog poglavlja (2/2)

• Snimi-i-pusti (record and playback) – alat koji snimi klikove testera i kasnije ih ponovi.
• Regresiona svita – automatski testovi koji se pokreću poslije svake izmjene, da se vidi da ništa nije pokvareno.
• pytest – najpopularniji okvir za testiranje u Pythonu.
• Izlaz testa – izvještaj okvira: koliko je testova prošlo, palo, i zašto.

Ciljevi poglavlja

Nakon poglavlja možete:

objasniti šta je automatizovan test i od čega se sastoji; izračunati od kojeg izvršavanja se automatizacija isplati; navesti šta ima smisla, a šta nema smisla automatizovati; objasniti piramidu testova i obrazac „ledenog konusa”; nabrojati vrste alata za automatizaciju i primjer za svaku; navesti osobine dobrog automatskog testa (FIRST); napisati provjeru u Pythonu naredbom assert; napisati, pokrenuti i pročitati izlaz testova u pytestu; pokrenuti iste testove nad obje verzije DeliveryApp i objasniti ulogu regresione svite.

Plan poglavlja – Sedmica 4: tri časa teorije i tri časa praktične nastave

4.1 Program koji testira program

Automatizovan test je mali program koji uradi ono što tester radi rukom, ali bez čovjeka:

1. pripremi ulaz (npr. dvije Margarite i sok, 4,2 km);
2. pozove dio sistema koji testira (ukupno(...));
3. uporedi stvarni rezultat s očekivanim (2450 centi);
4. javi rezultat: prošao ili pao, i ako je pao, zašto.

U Pythonu, najjednostavniji automatski test je jedan red:

assert ukupno([(950, 2), (250, 1)], 4.2) == 2450

4.1 Program koji testira program

Naredba assert (engleski „tvrdim”) provjerava da je izraz iza nje tačan. Ako jeste, ništa se ne desi i program ide dalje. Ako nije, program staje s greškom AssertionError. To je sve: test je tvrdnja o tome kako sistem mora raditi, napisana tako da je računar može provjeriti.

Automatizovani testovi se ne pišu svaki za sebe kao poseban program. Koristi se okvir za testiranje (test framework): alat koji sam pronađe sve testove u projektu, pokrene ih, izmjeri vrijeme i napiše uredan izvještaj. Za Python je to najčešće pytest, za Javu JUnit, za C# NUnit ili xUnit, za JavaScript Jest ili Vitest. Ideja je u svima ista.

Slika iz života: automatski test je kao mjerač pritiska u autu koji se sam uključi svaki put kad upalite motor i zasvijetli ako je pritisak u gumama nizak. Vi ne morate svaki dan izaći i mjeriti gume; mjerač to radi umjesto vas, uvijek na isti način.

Ukratko – 4.1 Program koji testira program

• Automatizovan test pripremi ulaz, pozove dio sistema, uporedi rezultat s očekivanim i javi ishod.
• Najjednostavniji test u Pythonu je jedan red s naredbom assert.
• Okvir za testiranje (pytest, JUnit) pronalazi, pokreće i izvještava o svim testovima.

4.2 Kada se automatizacija isplati

Automatski test nije besplatan. Treba ga napisati (vrijeme programera ili testera) i održavati (kad se sistem promijeni, i test se mijenja). Zauzvrat, izvršavanje ne košta ništa ljudskog vremena. Isplati li se?

Primjer: tim ima 40 testova cijene DeliveryApp. Ručno, svaki traje oko 2 minute, pa jedno izvršavanje svih traje 40 × 2 = 80 minuta. Automatizacija svih 40 traje 8 sati (480 minuta), a održavanje oko 10 minuta po izvršavanju (popravka testa kad se nešto promijeni). Poslije n izvršavanja:

Čemu služi. Formule porede ukupno ljudsko vrijeme. Automatizacija postaje jeftinija kad je 480 + 10n < 80n, odnosno 70n > 480, n > 6,9. Dakle, od sedmog izvršavanja automatski testovi štede vrijeme. Poslije 10 izvršavanja: ručno 800 minuta (preko 13 sati), automatski 580 minuta. A u stvarnosti se automatski testovi ne pokreću deset puta, nego pri svakoj izmjeni koda: ako tim napravi 5 izmjena dnevno, za dvije sedmice (10 radnih dana) to je 50 izvršavanja, ručno 4000 minuta (oko 67 sati), automatski 980 minuta. Ručno to niko ne bi ni uradio; testovi bi se jednostavno preskakali.

4.2 Kada se automatizacija isplati

Brojevi u ovom primjeru su izmišljeni, ali pravilo je opšte: automatizacija se isplati za testove koji se izvršavaju često, a ne isplati za test koji će se izvršiti jednom ili dvaput.

4.2 Kada se automatizacija isplati

Ukratko – 4.2 Kada se automatizacija isplati

• Automatski test košta pisanje i održavanje, a izvršavanje ne košta ljudsko vrijeme.
• U primjeru sa 40 testova automatizacija se isplati od sedmog izvršavanja (480 + 10n < 80n).
• Kad se testovi pokreću pri svakoj izmjeni, ručno testiranje postaje nemoguće.
• Automatizacija se isplati za testove koji se izvršavaju često.

4.3 Šta ne treba automatizovati

Automatizacija nije uvijek dobar izbor. Ne automatizuje se:

• ono što se još svaki dan mijenja: ekran koji dizajner prepravlja svaki dan; test bi se popravljao češće nego što bi pomagao;
• jednokratne provjere: provjera da je stara baza ispravno prebačena u novu, jednom;
• procjena izgleda i upotrebljivosti: „je li poruka jasna?”, „izgleda li dugme klikabilno?”; to procjenjuje čovjek (poglavlje 3);
• istraživanje: automat ponavlja ono što mu je rečeno, a istraživanje traži ono čega se niko nije sjetio;
• testovi čija je automatizacija skuplja od koristi: npr. provjera štampanja na stvarnom štampaču u kuhinji.

I obrnuto, uvijek se automatizuje:

4.3 Šta ne treba automatizovati

• pravila s mnogo kombinacija i granica (obračun cijene, popust, stanja narudžbe);
• regresija: sve što je jednom radilo i mora raditi i poslije svake izmjene;
• dim-test poslije svake isporuke;
• performanse: 200 simuliranih korisnika ne može glumiti 200 ljudi (poglavlje 10).

Ukratko – 4.3 Šta ne treba automatizovati

• Ne automatizuje se ono što se stalno mijenja, jednokratne provjere, procjena izgleda i istraživanje.
• Uvijek se automatizuju pravila s mnogo kombinacija, regresija, dim-test i performanse.
• Automatizacija ne zamjenjuje testera, nego ga oslobađa ponavljanja.

Provjeri se

1. Od čega se sastoji automatizovan test? Od pripreme ulaza, poziva sistema, poređenja s očekivanim rezultatom i javljanja ishoda.
2. Od kojeg izvršavanja se automatizacija u primjeru isplati? Od sedmog.
3. Treba li automatizovati procjenu da li je poruka o greški jasna? Ne; to procjenjuje čovjek.

Odgovori: tipka R ili klik na zamućeno polje.

4.4 Piramida testova

Automatski testovi postoje na svim nivoima iz poglavlja 2. Koliko kojih? Odgovor daje piramida testova, koju je popularizovao Mike Cohn u knjizi o agilnom razvoju iz 2009. godine:

• u podnožju su jedinični testovi: mnogo njih (stotine, hiljade), brzi (milisekunde), provjeravaju jednu funkciju i tačno pokazuju gdje je greška;
• u sredini su integracioni i API testovi: manje njih, sporiji (stotinke ili desetinke sekunde), provjeravaju saradnju dijelova;
• na vrhu su testovi kroz korisnički interfejs (end-to-end, s kraja na kraj): malo njih, spori (sekunde), krhki, ali provjeravaju sistem onako kako ga vidi korisnik.

Za DeliveryApp bi to moglo izgledati ovako:

4.4 Piramida testova

Zašto ne obrnuto? Testovi kroz ekran su spori, a kad padnu, ne kaže se jasno šta je pokvareno: da li pravilo, API, baza ili samo pomjereno dugme. Uz to su često nestabilni (flaky): ponekad padnu jer je stranica sporo učitana, a ne zbog defekta. Tim koji ima mnogo testova kroz ekran, a malo jediničnih, ima piramidu naopako, koju zovu ledeni konus (kao kornet sladoleda): testovi traju satima, često padaju bez razloga, i ljudi im prestanu vjerovati.

Pravilo: svako pravilo se testira na najnižem nivou na kojem se može provjeriti. Granica od 30,00 € testira se jediničnim testom funkcije cijena_dostave, a ne kroz web stranicu. Kroz web stranicu testira se samo da je ta funkcija zaista povezana s ekranom.

Ukratko – 4.4 Piramida testova

• Piramida testova: mnogo brzih jediničnih testova, manje integracionih i API testova, malo sporih testova kroz ekran.
• Testovi kroz ekran su spori, krhki i ne pokazuju tačno gdje je greška.
• Ledeni konus je piramida naopako: mnogo testova kroz ekran, malo jediničnih.
• Svako pravilo se testira na najnižem nivou na kojem se može provjeriti.

4.5 Vrste alata

Alati za automatizaciju dijele se po tome šta testiraju. Imena se brzo mijenjaju, ali vrste ostaju:

4.5 Vrste alata

4.5 Vrste alata

Posebna vrsta su alati snimi-i-pusti (record and playback): tester klikće po aplikaciji, alat snima klikove i kasnije ih ponavlja. Zvuči idealno, ali takvi testovi se lako pokvare: čim se dugme pomjeri ili preimenuje, snimak više ne radi. Danas se snimanje koristi kao početak (Playwright ima generator koda koji snimi klikove i napiše kod), a test se zatim doradi rukom: dobri lokatori, jasne provjere, bez nepotrebnih koraka.

Ukratko – 4.5 Vrste alata

• Alati se dijele na okvire za jedinične testove, pokrivenost, statičku analizu, API, preglednik, performanse, test dvojnike, CI i upravljanje testovima.
• Za Python u knjizi koristimo pytest, coverage.py, ruff, httpx, Playwright i Locust.
• Snimi-i-pusti alati su dobar početak, ali snimljen test se uvijek doradi rukom.

4.6 Osobine dobrog automatskog testa

Loš automatski test je gori od nikakvog: troši vrijeme, padne bez razloga i nauči tim da testovima ne vjeruje. Dobar automatski test ima pet osobina, koje se pamte po engleskoj riječi FIRST:

4.6 Osobine dobrog automatskog testa

Najčešća povreda je R. Test koji provjerava „vrijeme dostave je ispod 30 minuta” prolazi danas, a pada u petak u podne kad je gužva; test koji zove pravi servis mapa pada kad internet zakaže. Takvi testovi su nestabilni i u poglavlju 12 vidimo kako se liječe. Povreda S je također česta kod početnika: test koji samo ispiše print(ukupno(...)) nije test, jer čovjek mora pročitati broj i znati da li je dobar.

Ukratko – 4.6 Osobine dobrog automatskog testa

• Dobar automatski test je brz, nezavisan, ponovljiv, sam se provjerava i pravovremen (FIRST).
• Test koji zavisi od vremena, interneta ili redoslijeda je nestabilan.
• Test koji samo ispisuje rezultat nije test; mora sam reći prošao ili pao.

Provjeri se

1. Kojih testova u piramidi treba biti najviše? Jediničnih.
2. Šta je ledeni konus? Piramida naopako: mnogo sporih testova kroz ekran, a malo jediničnih.
3. Šta znači S u FIRST? Test sam kaže da li je prošao, bez čovjeka koji gleda ispis.

Odgovori: tipka R ili klik na zamućeno polje.

4.7 Provjera s assert

Tabela očekivanih rezultata iz poglavlja 1 može se direktno pretvoriti u program. Svaki red postaje jedna tvrdnja:

4.7 Provjera s assert

from deliveryapp import cijena_dostave, ukupno

slucajevi = [
    # (opis, km, artikli u centima, očekivana dostava u centima)
    ("T-01 do 3 km",          2,   1000, 200),
    ("T-02 tačno 3 km",       3,   1000, 200),
    ("T-03 3,1 km",           3.1, 1000, 250),
    ("T-04 4,2 km (N-1001)",  4.2, 2150, 300),
    ("T-05 tačno 10 km",      10,  1000, 550),
    ("T-07 tačno 30,00 €",    5,   3000,   0),
    ("T-08 29,99 €",          5,   2999, 300),
]
for opis, km, iznos, ocekivano in slucajevi:
    stvarno = cijena_dostave(km, iznos)
    assert stvarno == ocekivano, f"{opis}: očekivano {ocekivano}, stvarno {stvarno}"
print("sve provjere prošle")

4.7 Provjera s assert

Iza zareza u assert stoji poruka koja se ispiše ako tvrdnja padne. Dobra poruka kaže koji slučaj, šta je očekivano i šta je stvarno, isto kao izvještaj o defektu iz poglavlja 3.

Ovaj program je već automatski test. Ali ima dvije mane: staje na prvoj greški (ostale slučajeve ne provjeri), i ne pravi uredan izvještaj. Obje rješava okvir za testiranje.

Ukratko – 4.7 Provjera s assert

• Tabela očekivanih rezultata pretvara se u listu slučajeva i petlju s assert.
• Poruka uz assert kaže koji slučaj je pao, šta je očekivano i šta je stvarno.
• Običan program staje na prvoj greški i nema izvještaj; to rješava okvir za testiranje.

4.8 pytest

pytest je najpopularniji okvir za testiranje u Pythonu. Instalira se jednom naredbom (pip install pytest) i radi po jednostavnim dogovorima:

• testovi su u fajlovima čije ime počinje sa test_ (npr. test_prvi.py);
• svaki test je funkcija čije ime počinje sa test_;
• u funkciji se koristi obični assert.

Isti testovi kao u 4.7, u pytestu:

4.8 pytest

from deliveryapp import cijena_dostave, ukupno

def test_n1001_ukupno():
    assert ukupno([(950, 2), (250, 1)], 4.2) == 2450

def test_tacno_3_km():
    assert cijena_dostave(3, 1000) == 200

def test_3_1_km():
    assert cijena_dostave(3.1, 1000) == 250

def test_besplatna_od_30_eura():
    assert cijena_dostave(5, 3000) == 0

def test_29_99_eura():
    assert cijena_dostave(5, 2999) == 300

4.8 pytest

U terminalu, u folderu s fajlom, pokrećemo:

pytest -v

pytest sam pronađe sve funkcije test_…, izvrši ih sve (i ako neka padne) i napiše izvještaj. Nad ispravnom verzijom DeliveryApp:

test_prvi.py::test_n1001_ukupno PASSED
test_prvi.py::test_tacno_3_km PASSED
test_prvi.py::test_3_1_km PASSED
test_prvi.py::test_besplatna_od_30_eura PASSED
test_prvi.py::test_29_99_eura PASSED
5 passed in 0.02s

4.8 pytest

Bez opcije -v (verbose, opširno) pytest za svaki test ispiše samo jedan znak: . prošao, F pao (failed: tvrdnja nije tačna), E greška (error: test se nije ni mogao izvršiti, npr. pogrešno ime funkcije).

Kad test padne, pytest pokaže tačno šta je dobio, iako u assert nismo napisali poruku. Na primjer, kad bismo testirali prvu verziju DeliveryApp:

    def test_n1001_ukupno():
>       assert ukupno([(950, 2), (250, 1)], 4.2) == 2450
E       assert 2400 == 2450

Ovo je pytestova posebna snaga: razloži tvrdnju i ispiše obje strane. Odmah vidimo da je ukupno za N-1001 2400 centi (24,00 €) umjesto 2450: dostava je 2,50 € umjesto 3,00 €. Defekt je negdje u obračunu dostave, a test ne kaže gdje. To je posao debagovanja, ali test je suzio traženje na jednu funkciju.

Ukratko – 4.8 pytest

• pytest pronalazi fajlove test_.py i funkcije test_, izvršava ih sve i piše izvještaj.
• Naredba pytest -v ispisuje svaki test; bez -v znakovi su . (prošao), F (pao) i E (greška).
• Kad test padne, pytest pokaže obje strane tvrdnje, npr. assert 2400 == 2450.
• Test sužava traženje defekta, a debagovanje ga nalazi.

4.9 Regresiona svita: mreža za sigurnost

Kad testovi postoje, mogu se pokretati uvijek: poslije svake izmjene koda, kod svakog programera, na serveru za kontinuiranu integraciju. Takav skup testova zove se regresiona svita, i ona je mreža za sigurnost ispod akrobata: programer smije mijenjati kod hrabro, jer će svita uhvatiti ako je pokvario nešto što je ranije radilo.

U folderu primjeri/deliveryapp/tests/ nalazi se svita od 27 testova pravila DeliveryApp (fajl test_granice.py). Isti testovi mogu se pokrenuti nad obje verzije koda: fajl conftest.py u istom folderu, kad je postavljena promjenljiva okruženja DeliveryApp=v0, umjesto ispravnog modula deliveryapp učita prvu verziju deliveryapp_v0.

pytest tests/test_granice.py    # ispravna verzija
27 passed in 0.13s

set DeliveryApp=v0                  # u Windows Command Promptu; u PowerShellu $env:DeliveryApp="v0"; u Linuxu export DeliveryApp=v0
pytest tests/test_granice.py    # prva verzija
8 failed, 19 passed in 0.07s

4.9 Regresiona svita: mreža za sigurnost

Osam testova pada na prvoj verziji. Koji su to testovi i koje defekte otkrivaju, analiziraćemo u poglavlju 8. Za sada je važna lekcija: ista svita, ista sekunda, dva potpuno različita rezultata. Kad programeri isprave prvu verziju, ista svita će reći da li su ispravili sve, i da li su usput pokvarili nešto drugo.

Ukratko – 4.9 Regresiona svita: mreža za sigurnost

• Regresiona svita su automatski testovi koji se pokreću poslije svake izmjene, kao mreža za sigurnost.
• Svita DeliveryApp ima 27 testova; nad ispravnom verzijom svi prolaze, a nad prvom verzijom 8 pada.
• Promjenljiva DeliveryApp=v0 bira prvu verziju bez mijenjanja testova.
• Ista svita kasnije potvrđuje ispravke i hvata nove regresije.

Provjeri se

1. Kako pytest prepoznaje test? Po imenu fajla test_.py i imenu funkcije test_.
2. Šta znači F u izlazu pytesta? Test je pao, jer tvrdnja nije tačna.
3. Koliko testova svite pada na prvoj verziji DeliveryApp? Osam od 27.

Odgovori: tipka R ili klik na zamućeno polje.

Praktična nastava – prvi automatski testovi

Cilj je da tabela očekivanih rezultata iz poglavlja 1 postane automatski test u pytestu, da se pokrene nad obje verzije DeliveryApp i da se izmjeri koliko se štedi. Radi se u repozitoriju deliveryapp-testovi.

Korak 1 – Instalacija

1. U terminalu: pip install pytest. Provjerite: pytest --version.
2. U repozitorij kopirajte deliveryapp.py, deliveryapp_v0.py i folder tests/ iz primjeri/deliveryapp/.

Korak 2 – Provjera s assert

1. Napravite prva_provjera.py po uzoru na 4.7, sa svim redovima vaše tabele iz ocekivano.md (poglavlje 1) koji su o cijeni dostave i ukupnom iznosu.
2. Pokrenite python prva_provjera.py. Mora ispisati „sve provjere prošle”.
3. Promijenite import u from deliveryapp_v0 import … i pokrenite ponovo. Na kojem slučaju je program stao? Zašto ostale nije provjerio?

Korak 3 – Isti testovi u pytestu

1. Napravite tests/test_prvi.py i svaki red tabele pretvorite u posebnu funkciju test_… s jasnim imenom (npr. test_tacno_30_eura_besplatno).
2. Pokrenite pytest -v tests/test_prvi.py. Svi testovi moraju proći nad ispravnom verzijom.
3. Pokrenite nad prvom verzijom (DeliveryApp=v0, kako je opisano u 4.9). Zapišite koje funkcije padaju i šta pytest kaže da je dobio (red s E assert …).
4. Uporedite s otkazima koje ste našli ručno u poglavlju 1 i 3. Jesu li isti?

Korak 4 – Gotova svita

1. Pokrenite pytest -v tests/test_granice.py (gotova svita iz primjeri/). Zapišite broj testova i vrijeme.
2. Isto nad prvom verzijom. Zapišite: koliko testova pada; koji je od njih pao i u vašoj tabeli, a koji nije (to su slučajevi koje niste imali).

Korak 5 – Namjerni defekt

U ispravnoj verziji deliveryapp.py namjerno napravite jednu sitnu grešku (npr. MAX_KM = 11 ili PO_KM = 40) i pokrenite svitu. Koji testovi padaju? Da li bi vaš test_prvi.py sam otkrio tu grešku? Vratite ispravku i provjerite da je opet sve zeleno. Ovo je regresiono testiranje u malom.

Korak 6 – Računica isplativosti

Izmjerite štopericom koliko vam traje ručno izvršavanje 10 testova iz tabele (na Python konzoli ili web stranici), i koliko vam je trajalo pisanje test_prvi.py. Izračunajte, po formulama iz 4.2, od kojeg izvršavanja se automatizacija vama isplatila.

Korak 7 – AI kao pomoćnik (opcionalno)

Dajte AI asistentu svoju tabelu iz ocekivano.md i zatražite da je pretvori u pytest testove. Pokrenite ih nad ispravnom verzijom. Ako neki pada nad ispravnom verzijom, ko je pogriješio: AI (pogrešan očekivani rezultat ili pogrešni centi) ili kod? Zapišite primjer.

Rezultat koji se predaje: prva_provjera.py, tests/test_prvi.py, i fajl rezultati-4.md s izlazom pytesta nad obje verzije (broj prošlih i palih, imena palih testova), rezultatom koraka 5 i računicom iz koraka 6.

Vježba za studenta 1 – isplativost.

Vježba za studenta 1 – isplativost. – rješenje

Vježba za studenta 2 – automatizovati ili ne.

Vježba za studenta 2 – automatizovati ili ne. – rješenje

Vježba za studenta 3 – piramida.

Vježba za studenta 3 – piramida. – rješenje

Vježba za studenta 4 – FIRST.

Vježba za studenta 4 – FIRST. – rješenje

Vježba za studenta 5 – čitanje izlaza.

Vježba za studenta 5 – čitanje izlaza. – rješenje

Sažetak u pet rečenica

1. Netflixov Chaos Monkey pokazuje ideju automatizacije: ono što se može provjeriti automatski provjerava se stalno, bez umora, a ne jednom pred isporuku.
2. Automatizovan test priprema ulaz, poziva sistem, poredi s očekivanim i javlja ishod, a isplati se za testove koji se izvršavaju često, u primjeru od sedmog izvršavanja.
3. Piramida testova traži mnogo brzih jediničnih, manje integracionih i malo testova kroz ekran, a svako pravilo se testira na najnižem mogućem nivou.
4. Dobar automatski test je brz, nezavisan, ponovljiv, sam se provjerava i pravovremen, a ne automatizuje se ono što se stalno mijenja, procjena izgleda i istraživanje.
5. pytest pronalazi i izvršava testove i pokazuje obje strane pale tvrdnje, a regresiona svita DeliveryApp od 27 testova nad ispravnom verzijom prolazi za desetinku sekunde, dok nad prvom verzijom 8 testova pada.

Pitanja za ponavljanje

1. Šta je Chaos Monkey i kakve veze ima s automatizacijom testiranja?
2. Od kojih koraka se sastoji automatizovan test?
3. Šta je okvir za testiranje? Navedite tri primjera za različite jezike.
4. Kako se računa isplativost automatizacije? Izračunajte primjer sa 40 testova.
5. Šta ne treba automatizovati, a šta uvijek treba?
6. Šta je piramida testova i zašto je ledeni konus problem?
7. Navedite pet vrsta alata za automatizaciju i primjer za svaku.
8. Koja je mana alata snimi-i-pusti?
9. Objasnite osobine FIRST.
10. Kako radi naredba assert i šta je poruka uz nju?
11. Po kojim pravilima pytest pronalazi testove?
12. Šta znače znakovi ., F i E u izlazu pytesta?
13. Šta je regresiona svita i zašto je mreža za sigurnost?
14. Kako se ista svita pokreće nad obje verzije DeliveryApp i kakav je rezultat?