Használja a teszteket bizonyítékként

Kezdje a követelménnyel

A tesztek meghatározott állítások bizonyítékai. Egy sikeres tesztfuttatás nem igazolja a szoftver minden tulajdonságát. Tesztek kérése előtt azonosítsa a fontos működést és azt a hibát, amelyet az egyes ellenőrzéseknek észlelniük kell.

Egy fiktív, szervezeti adatokat exportáló funkciónál a fő követelmény az adatelkülönítés. Az A szervezet felhasználója nem kaphatja meg a B szervezet rekordjait. A csak sikeres letöltést vizsgáló teszt nem bizonyítja ezt a követelményt.

Kérje meg az agentet, hogy magyarázza el a követelmény és az assertion kapcsolatát. Így a hiányzó esetek még a tesztkészlet megnövekedése előtt könnyebben felismerhetők.

Válassza meg a teszt megfelelő hatókörét

A unit test gyorsan ellenőrizhet kis átalakítást. Az integrációs teszt a komponensek együttműködését vizsgálhatja. Az end-to-end teszt fontos felhasználói műveletsort ellenőrizhet a telepített vagy azt megfelelően képviselő alkalmazáson.

A szükséges bizonyítékot adó legszűkebb hatókört használja. Egy formázónál nem kell minden bemenethez teljes böngészőteszt. Jogosultsági határhoz valódi route-ra és adatelérési útvonalra lehet szükség. Kritikus böngészős interakciónál a megjelenített felületről kell bizonyíték.

A teszttípusoknak nincs minden rendszerhez megfelelő állandó százalékos aránya. Az észlelendő hiba és az ellenőrzés karbantartási költsége alapján válasszon.

Kerülje a közös hibás feltételezést

Az agent ugyanabból a félreértésből írhatja a megvalósítást és a teszteket. Egyezhetnek egymással úgy, hogy a követelmény továbbra sem teljesül.

Tegyük fel, hogy a megvalósítás a kérésben kapott szervezetazonosító alapján szűri a rekordokat. A teszt ugyanazt az azonosítót használja a bejelentkezett felhasználónál és a kérésben. Sikeres lesz. A hiányzó eset az, amikor a felhasználó más szervezet azonosítójával küld kérést.

Adja hozzá ezt az esetet a valódi, megbízható identitás- és jogosultság-ellenőrzési útvonalon. A mindig „engedélyezett” választ adó mock nem bizonyíthatja a tenantok elkülönítését. Csak a sikeres jogosultság-ellenőrzés utáni működést igazolja.

Ellenőrizze, hogy a teszt képes-e hibát jelezni

Ismert hibánál futtassa az új regressziós tesztet a hibás verzión, elkülönített ágon. Győződjön meg arról, hogy a várt okból sikertelen. Ezután alkalmazza a javítást, és futtassa újra.

Ha egy teszt azért sikertelen, mert nem tölthető be a tesztadata, az még nem bizonyíték az üzleti működésről. A hibát vizsgálja meg, ne csak a kilépési kódot.

Nagyobb módosításoknál a mutation testing segíthet felmérni, hogy meghatározott kódváltozások kiváltanak-e teszthibát. Ennek költsége van, és nem helyettesíti a követelmények review-ját. Ott használja, ahol a többletbizonyíték jelentős következményű döntést támogat.

A bizonyíték kapcsolódjon a módosításhoz

A releváns ellenőrzéseket a végső verzión futtassa. Rögzítse a kihagyott ellenőrzéseket és azok okát. Egy korábbi commit eredménye a review-javítás után már nem feltétlenül érvényes.

A tesztek maradjanak érthetőek. Az egyértelmű előkészítést és assertiont részesítse előnyben a fontos feltételt elrejtő nagy helperrel szemben. Távolítsa el a redundáns ellenőrzéseket, ha eltérő hiba észlelése nélkül növelik a karbantartási költséget.

A reviewernek el kell tudnia mondani, mit bizonyítanak a tesztek, és mi marad bizonytalan. Ez a magyarázat hasznosabb, mint a nagy tesztszám.