Upotrebljavajte testove kao dokaze

Počnite zahtjevom

Testovi su dokazi za konkretne tvrdnje. Uspješno pokretanje testova ne potvrđuje svako svojstvo softvera. Prije traženja testova utvrdite važno ponašanje i pogrešku koju svaka provjera treba otkriti.

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

Zatražite da agent objasni odnos između zahtjeva i tvrdnje u testu. 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 korisnički slijed kroz postavljenu ili reprezentativnu aplikaciju.

Upotrijebite najuži opseg koji daje potrebne dokaze. Alat za formatiranje ne treba potpuni test preglednika za svaki ulaz. Autorizacijska granica može zahtijevati stvarnu rutu i put pristupa podacima. Kritična interakcija u pregledniku treba dokaze o prikazanom sučelju.

Nijedan fiksni omjer vrsta testova ne odgovara svakom sustavu. Birajte prema pogrešci koju trebate otkriti i trošku održavanja provjere.

Izbjegnite zajedničku pogrešnu pretpostavku

Agent može napisati implementaciju i testove iz istog pogrešnog razumijevanja. Mogu se slagati, a da zahtjev ostane neispunjen.

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

Dodajte taj slučaj kroz stvarni pouzdani identitet i put autorizacije. Simulacija koja uvijek vraća „dopušteno” ne može potvrditi izolaciju tenanata. Potvrđuje samo ponašanje nakon uspješne autorizacije.

Provjerite može li test pasti

Za poznatu pogrešku pokrenite novi regresijski test na neispravnoj verziji u izoliranoj grani. Potvrdite da pada zbog namjeravanog razloga. Zatim primijenite ispravak i ponovno ga pokrenite.

Test koji pada jer se testni podaci ne mogu učitati još nije dokaz o poslovnom ponašanju. Pregledajte neuspjeh, a 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. Upotrijebite ga tamo gdje dodatni dokazi podupiru odluku s važnim posljedicama.

Zadržite vezu dokaza i promjene

Pokrenite relevantne provjere na konačnoj reviziji. Zabilježite preskočene provjere i razloge. Rezultat ranijeg commita možda više ne vrijedi nakon ispravka iz pregleda.

Testovi trebaju ostati razumljivi. Dajte prednost izričitoj pripremi i tvrdnji u testu pred velikom pomoćnom funkcijom koja skriva važan uvjet. Uklonite suvišne provjere ako povećavaju trošak održavanja bez otkrivanja drugačijeg kvara.

Pregledavatelj treba moći reći što testovi potvrđuju i što ostaje neizvjesno. To je objašnjenje korisnije od velikog broja testova.