Poglavlje 4: Automatizovano testiranje
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.
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.
Literatura. Osnovna literatura predmeta:
- J. Popović: Priručnik za test inženjere, CET i Računarski fakultet, Beograd, 2023.
- Rakić-Skoković: Priručnik za testiranje softvera, Fakultet tehničkih nauka, Novi Sad, 2013.
- G. J. Myers: The Art of Software Testing, 2. izdanje, John Wiley & Sons, 2004.
- A. P. Mathur: Foundations of Software Testing, Addison-Wesley Professional, 2008.
Za ovo i naredno poglavlje: B. Okken: Python Testing with pytest, 2nd ed., Pragmatic Bookshelf, 2022.
Riječi ovog poglavlja.
- 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.
- 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
| Čas | Sadržaj | Na času |
|---|---|---|
| Teorija 1 | 4.1–4.3 Automatski test; isplativost; šta ne automatizovati | Od 7. izvršavanja automatizacija je jeftinija |
| Teorija 2 | 4.4–4.6 Piramida; alati; osobine dobrog testa | Piramida i ledeni konus |
| Teorija 3 | 4.7–4.9 assert; pytest; regresija |
27 testova za desetinku sekunde; 8 padova na v0 |
| Praksa 1–3 | Tabela iz poglavlja 1 kao pytest testovi | test_prvi.py nad obje verzije |
Dio 1 – Zašto i kada automatizovati
4.1 Program koji testira program
Automatizovan test je mali program koji uradi ono što tester radi rukom, ali bez čovjeka:
- pripremi ulaz (npr. dvije Margarite i sok, 4,2 km);
- pozove dio sistema koji testira (
ukupno(...)); - uporedi stvarni rezultat s očekivanim (2450 centi);
- 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) == 2450Naredba 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.
- 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:
\[ T_{\text{ručno}} = 80\,n, \qquad T_{\text{auto}} = 480 + 10\,n \]
Č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.
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.
Broj za pamćenje. 27 automatskih testova cijene DeliveryApp izvrši se za desetinku sekunde. Ručno bi trajali skoro sat.
Ukratko.
- 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:
- 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).
Česta zabluda. „Kad sve automatizujemo, ne trebaju nam testeri.” Automatski test provjerava samo ono što je neko smislio i napisao. Smišljanje dobrih testova, istraživanje i procjena kvaliteta ostaju ljudski posao. Automatizacija oslobađa testera od ponavljanja da bi imao vremena za razmišljanje.
Ukratko.
- 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.
- Od čega se sastoji automatizovan test? – Od pripreme ulaza, poziva sistema, poređenja s očekivanim rezultatom i javljanja ishoda.
- Od kojeg izvršavanja se automatizacija u primjeru isplati? – Od sedmog.
- Treba li automatizovati procjenu da li je poruka o greški jasna? – Ne; to procjenjuje čovjek.
Dio 2 – Piramida testova i alati
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:
| Sloj | Primjeri | Broj | Trajanje svih |
|---|---|---|---|
| kroz ekran | Playwright: N-1001 kroz web stranicu, otkazivanje | 5–10 | nekoliko sekundi |
| API i integracija | POST /v1/cijena, API + baza |
20–40 | ispod sekunde do par sekundi |
| jedinični | cijena_dostave, popust, Narudzba.promijeni |
100+ | ispod sekunde |
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.
- 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:
| Vrsta | Šta radi | Primjeri | U knjizi |
|---|---|---|---|
| okvir za jedinične testove | pokreće testove funkcija i klasa | pytest (Python), JUnit (Java), NUnit/xUnit (C#), Jest (JavaScript) | 4, 5, 11 |
| mjerenje pokrivenosti | pokazuje koji dio koda su testovi izvršili | coverage.py, JaCoCo | 6 |
| statička analiza | čita kod i nalazi sumnjiva mjesta bez pokretanja | ruff, pylint, mypy, SonarQube | 7 |
| testiranje API-ja | šalje HTTP zahtjeve i provjerava odgovore | httpx, requests, Postman, HTTPie | 9 |
| testiranje kroz preglednik | upravlja preglednikom kao korisnik | Playwright, Selenium, Cypress | 13 |
| performanse i opterećenje | glumi mnogo istovremenih korisnika | Locust, k6, JMeter | 10 |
| test dvojnici | glume dijelove sistema koje ne želimo zvati | unittest.mock, pytest-mock | 9, 11 |
| kontinuirana integracija | pokreće sve testove pri svakoj izmjeni | GitHub Actions, GitLab CI, Jenkins | 14 |
| upravljanje testovima | vodi test slučajeve, izvršavanja i defekte | Jira s dodacima, TestRail, Xray | 14 |
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.
- 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:
| Slovo | Osobina | Značenje | Primjer u DeliveryApp |
|---|---|---|---|
| F | brz (fast) | izvršava se u milisekundama, pa ga niko ne preskače | jedinični test cijene, a ne cijela web stranica |
| I | nezavisan (independent) | ne zavisi od drugih testova ni od redoslijeda | svaki test pravi svoju narudžbu |
| R | ponovljiv (repeatable) | daje isti rezultat svaki put, na svakom računaru | ne zavisi od današnjeg datuma, interneta ni slučajnih brojeva |
| S | sam se provjerava (self-validating) | sam kaže prošao ili pao; ne treba čovjek da gleda ispis | assert, a ne print i gledanje |
| T | pravovremen (timely) | piše se uz kod, a ne mjesecima kasnije | test za PP-5 uz kod popusta |
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.
- 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.
- Kojih testova u piramidi treba biti najviše? – Jediničnih.
- Šta je ledeni konus? – Piramida naopako: mnogo sporih testova kroz ekran, a malo jediničnih.
- Šta znači S u FIRST? – Test sam kaže da li je prošao, bez čovjeka koji gleda ispis.
Dio 3 – Prvi automatski test
4.7 Provjera s assert
Tabela očekivanih rezultata iz poglavlja 1 može se direktno pretvoriti u program. Svaki red postaje jedna tvrdnja:
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")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.
- 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:
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) == 300U terminalu, u folderu s fajlom, pokrećemo:
pytest -vpytest 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.02sBez 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 == 2450Ovo 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.
- 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.07sOsam 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.
Iz stvarnog svijeta. Velike firme danas imaju stotine hiljada automatskih testova koji se pokreću hiljadama puta dnevno. Razlog nije da vole testove, nego da bez njih ne bi mogle mijenjati kod brzo: niko ne bi smio dirati sistem koji koriste milioni ljudi bez mreže za sigurnost.
Ukratko.
- 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.
- Kako pytest prepoznaje test? – Po imenu fajla test_.py i imenu funkcije test_.
- Šta znači F u izlazu pytesta? – Test je pao, jer tvrdnja nije tačna.
- Koliko testova svite pada na prvoj verziji DeliveryApp? – Osam od 27.
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
- U terminalu:
pip install pytest. Provjerite:pytest --version. - U repozitorij kopirajte
deliveryapp.py,deliveryapp_v0.pyi foldertests/izprimjeri/deliveryapp/.
Korak 2 – Provjera s assert
- Napravite
prva_provjera.pypo uzoru na 4.7, sa svim redovima vaše tabele izocekivano.md(poglavlje 1) koji su o cijeni dostave i ukupnom iznosu. - Pokrenite
python prva_provjera.py. Mora ispisati „sve provjere prošle”. - 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
- Napravite
tests/test_prvi.pyi svaki red tabele pretvorite u posebnu funkcijutest_…s jasnim imenom (npr.test_tacno_30_eura_besplatno). - Pokrenite
pytest -v tests/test_prvi.py. Svi testovi moraju proći nad ispravnom verzijom. - 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 sE assert …). - Uporedite s otkazima koje ste našli ručno u poglavlju 1 i 3. Jesu li isti?
Korak 4 – Gotova svita
- Pokrenite
pytest -v tests/test_granice.py(gotova svita izprimjeri/). Zapišite broj testova i vrijeme. - 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žbe
Vježba za studenta 1 – isplativost.
Ručno izvršavanje 25 testova traje po 3 minute. Automatizacija svih traje 6 sati, a održavanje 15 minuta po izvršavanju. Od kojeg izvršavanja se automatizacija isplati?
Rješenje. Ručno: 25 × 3 = 75 minuta po izvršavanju. Automatski: 360 + 15n. Isplati se kad je 360 + 15n < 75n, odnosno 60n > 360, n > 6. Dakle od sedmog izvršavanja (kod šestog su jednaki: 450 = 450).
Vježba za studenta 2 – automatizovati ili ne.
Za svaki test odlučite: automatizovati ili ručno? a) popust STUDENT10 na 50 iznosa; b) da li je nova boja dugmeta „Naruči” prijatna; c) jednokratni prenos 3000 starih narudžbi u novu bazu; d) dim-test poslije svake isporuke; e) istraživanje nove funkcije „zakaži za sutra”.
Rješenje. a) automatizovati (mnogo kombinacija, regresija); b) ručno (procjena izgleda); c) ručno ili jednokratnom skriptom koja se ne održava kao test (provjera prenosa); d) automatizovati; e) ručno (istraživanje), a nalaze kasnije pretvoriti u automatske testove.
Vježba za studenta 3 – piramida.
Tim ima 200 testova kroz web stranicu, 20 API testova i 15 jediničnih testova. Cijela svita traje 2 sata i svaki dan nekoliko testova padne „bez razloga”. Šta je problem i šta biste predložili?
Rješenje. To je ledeni konus: previše sporih i krhkih testova kroz ekran, premalo jediničnih. Prijedlog: pravila (cijena, popust, stanja) prebaciti u jedinične testove, povezivanje provjeriti API testovima, a kroz ekran ostaviti desetak testova najvažnijih tokova. Nestabilne testove istražiti i popraviti (poglavlje 12) ili privremeno izdvojiti.
Vježba za studenta 4 – FIRST.
Koje slovo FIRST krši svaki test? a) test šalje zahtjev pravom servisu mapa na internetu; b) test test_otkazi radi samo ako je prije njega pokrenut test_napravi_narudzbu; c) test ispisuje ukupnu cijenu, a tester gleda da li je 24,50; d) test traje 40 sekundi jer svaki put pokreće cijeli preglednik za provjeru funkcije popusta.
Rješenje. a) R (ponovljiv: zavisi od interneta i servisa); b) I (nezavisan); c) S (sam se provjerava); d) F (brz); test popusta treba biti jedinični.
Vježba za studenta 5 – čitanje izlaza.
pytest je ispisao: ..F.E i ispod toga E assert 200 == 250 za treći test, te NameError: name 'cijena_dostav' is not defined za peti. Šta se desilo sa svakim od pet testova?
Rješenje. Prvi, drugi i četvrti su prošli (tačke). Treći je pao (F): funkcija je vratila 200, a očekivano je 250, što liči na dostavu za 3,1 km bez započetog kilometra. Peti je greška (E): test se nije mogao izvršiti jer je ime funkcije pogrešno napisano (cijena_dostav); to je greška u testu, a ne u sistemu.
Sažetak u pet rečenica
- Netflixov Chaos Monkey pokazuje ideju automatizacije: ono što se može provjeriti automatski provjerava se stalno, bez umora, a ne jednom pred isporuku.
- 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.
- 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.
- 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.
- 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.