Používajte testy ako dôkazy

Začnite požiadavkou

Testy sú dôkazmi pre konkrétne tvrdenia. Úspešné spustenie testov nepreukazuje každú vlastnosť softvéru. Pred zadaním testov určte dôležité správanie a chybu, ktorú má každá kontrola odhaliť.

Pri fiktívnom exporte organizácie je hlavnou požiadavkou izolácia údajov. Používateľ organizácie A nesmie dostať záznamy organizácie B. Test, ktorý kontroluje iba úspešné stiahnutie, túto požiadavku nepreukazuje.

Požiadajte agenta, aby vysvetlil vzťah medzi požiadavkou a testovým tvrdením. Takto ľahšie odhalíte chýbajúce prípady skôr, než sa súbor testov rozrastie.

Vyberte vhodný rozsah testu

Jednotkový test môže rýchlo skontrolovať malú transformáciu. Integračný test môže skontrolovať spoluprácu komponentov. End-to-end test môže skontrolovať dôležitý postup používateľa cez nasadenú alebo reprezentatívnu aplikáciu.

Použite najmenší rozsah, ktorý poskytne potrebné dôkazy. Formátovacia funkcia nepotrebuje úplný test v prehliadači pre každý vstup. Autorizačná hranica môže vyžadovať skutočnú route a cestu prístupu k údajom. Kritická interakcia v prehliadači potrebuje dôkazy o vykreslenom rozhraní.

Žiadny pevný percentuálny pomer typov testov nevyhovuje každému systému. Vyberajte podľa zlyhania, ktoré potrebujete odhaliť, a nákladov na údržbu kontroly.

Vyhnite sa spoločnému nesprávnemu predpokladu

Agent môže napísať implementáciu aj testy na základe rovnakého nedorozumenia. Obe časti sa môžu zhodovať, hoci požiadavka zostáva nesplnená.

Predstavte si, že implementácia filtruje záznamy podľa ID organizácie z požiadavky. Test používa rovnaké ID pre prihláseného používateľa aj požiadavku. Uspeje. Chýba prípad používateľa, ktorý v požiadavke uvedie ID inej organizácie.

Pridajte tento prípad cez skutočnú cestu dôveryhodnej identity a autorizácie. Mock, ktorý vždy vráti „povolené“, nemôže preukázať izoláciu tenantov. Preukazuje iba správanie po úspešnej autorizácii.

Overte, že test môže zlyhať

Pri známej chybe spustite nový regresný test proti chybnej verzii v izolovanej vetve. Overte, že zlyhá z očakávaného dôvodu. Potom použite opravu a test spustite znova.

Test, ktorý zlyhá, pretože nemožno načítať testovacie dáta, ešte nie je dôkazom o požadovanom správaní aplikácie. Preskúmajte zlyhanie, nielen návratový kód.

Pri širších zmenách môže mutačné testovanie pomôcť posúdiť, či vybrané zmeny kódu spôsobia zlyhanie testov. Má svoje náklady a nenahrádza kontrolu požiadaviek. Použite ho tam, kde dodatočné dôkazy podporia rozhodnutie so závažnými dôsledkami.

Udržujte dôkazy prepojené so zmenou

Relevantné kontroly spustite na konečnej verzii. Zaznamenajte vynechané kontroly a ich dôvody. Výsledok zo skoršieho commitu už po oprave z kontroly nemusí platiť.

Udržujte testy zrozumiteľné. Uprednostnite výslovnú prípravu a tvrdenie pred veľkou pomocnou funkciou, ktorá skrýva dôležitú podmienku. Odstráňte nadbytočné kontroly, ak zvyšujú náklady na údržbu bez odhalenia iného zlyhania.

Kontrolujúca osoba má vedieť uviesť, čo testy preukazujú a čo zostáva neisté. Toto vysvetlenie je užitočnejšie ako vysoký počet testov.