Koristite testove kao dokaze

Počnite od zahtjeva

Testovi su dokazi za određene tvrdnje. Uspješno izvršeni testovi ne potvrđuju svako svojstvo softvera. Prije traženja testova utvrdite važno ponašanje i grešku koju svaka provjera treba otkriti.

Za izmišljeni izvoz podataka organizacije glavni zahtjev je izolacija podataka. Korisnik organizacije A ne smije dobiti zapise organizacije B. Test koji provjerava samo uspješno preuzimanje ne potvrđuje ovaj zahtjev.

Zatražite da agent objasni vezu između zahtjeva i tvrdnje koju test provjerava. Tako je lakše otkriti slučajeve koji nedostaju prije nego što skup testova postane velik.

Odaberite odgovarajući opseg testa

Jedinični test može brzo provjeriti malu transformaciju. Integracijski test može provjeriti kako komponente rade zajedno. End-to-end test može provjeriti važan niz korisničkih koraka kroz raspoređenu ili reprezentativnu aplikaciju.

Koristite najuži opseg koji daje potrebne dokaze. Alat za formatiranje ne treba potpuni test u pregledniku za svaki ulaz. Granica autorizacije može zahtijevati stvarnu rutu i put pristupa podacima. Kritična interakcija u pregledniku treba dokaze o prikazanom interfejsu.

Nijedan fiksni postotak vrsta testova ne odgovara svakom sistemu. Birajte prema neuspjehu koji trebate otkriti i trošku održavanja provjere.

Izbjegnite zajedničku pogrešnu pretpostavku

Agent može napisati implementaciju i testove na osnovu istog pogrešnog razumijevanja. Oboje se mogu slagati, a da zahtjev ostane neispunjen.

Pretpostavite da implementacija filtrira zapise prema ID-ju organizacije dostavljenom u zahtjevu. Test koristi isti ID za prijavljenog korisnika i zahtjev. Test prolazi. Nedostaje slučaj u kojem korisnik traži ID druge organizacije.

Dodajte taj slučaj kroz stvarni pouzdani identitet i put autorizacije. Mock koji uvijek vraća „dozvoljeno“ ne može potvrditi izolaciju zakupaca. Potvrđuje samo ponašanje nakon uspješne autorizacije.

Provjerite može li test pasti

Za poznatu grešku pokrenite novi regresijski test nad verzijom s greškom na izolovanoj grani. Potvrdite da pada iz namjeravanog razloga. Zatim primijenite ispravku i ponovo ga pokrenite.

Test koji pada zato što se testni podaci ne mogu učitati još nije dokaz o poslovnom ponašanju. Pregledajte razlog pada, ne samo izlazni kod.

Za šire promjene, mutacijsko testiranje može pomoći procijeniti uzrokuju li odabrane promjene koda pad testova. Ono ima trošak i ne zamjenjuje pregled zahtjeva. Koristite ga tamo gdje dodatni dokazi podržavaju odluku s važnim posljedicama.

Povežite dokaze s promjenom

Izvršite relevantne provjere na konačnoj reviziji koda. Zabilježite preskočene provjere i razloge. Rezultat ranijeg commita možda više ne vrijedi nakon ispravke tokom pregleda.

Neka testovi budu razumljivi. Dajte prednost izričitoj pripremi i provjeri tvrdnje u odnosu na veliki pomoćni mehanizam koji skriva važan uslov. Uklonite suvišne provjere kada povećavaju trošak održavanja bez otkrivanja drugačijeg neuspjeha.

Osoba zadužena za pregled treba moći navesti šta testovi potvrđuju i šta ostaje neizvjesno. To objašnjenje korisnije je od velikog broja testova.