Používejte testy jako důkazy

Začněte požadavkem

Testy jsou důkazy pro konkrétní tvrzení. Úspěšný běh testů neprokazuje všechny vlastnosti softwaru. Než o testy požádáte, určete důležité chování a chybu, kterou má každá kontrola odhalit.

U fiktivního exportu organizace je hlavním požadavkem izolace dat. Uživatel organizace A nesmí dostat záznamy organizace B. Test, který ověří jen úspěšné stažení, tento požadavek neprokazuje.

Požádejte agenta, aby vysvětlil vztah mezi požadavkem a ověřovanou podmínkou. Chybějící případy tak snáze odhalíte dříve, než sada testů naroste.

Zvolte vhodný rozsah testu

Unit test může rychle ověřit malou transformaci. Integrační test ověřuje spolupráci komponent. End-to-end test může ověřit důležitou posloupnost uživatelských kroků v nasazené aplikaci nebo jejím reprezentativním prostředí.

Použijte nejužší rozsah, který dodá potřebný důkaz. Formátovací funkce nepotřebuje kompletní test v prohlížeči pro každý vstup. Autorizační hranice může vyžadovat skutečnou cestu požadavku a přístupu k datům. Důležitá interakce v prohlížeči potřebuje důkazy o vykresleném rozhraní.

Žádný pevný procentní poměr typů testů se nehodí pro každý systém. Rozhodujte podle selhání, které potřebujete odhalit, a nákladů na údržbu kontroly.

Zabraňte společnému chybnému předpokladu

Agent může napsat implementaci i testy na základě stejného nedorozumění. Mohou se shodovat, a přesto požadavek zůstane nesplněný.

Předpokládejme, že implementace filtruje záznamy podle ID organizace dodaného v požadavku. Test použije stejné ID pro přihlášeného uživatele i požadavek. Projde. Chybí případ, kdy uživatel požaduje ID jiné organizace.

Přidejte tento případ přes skutečnou důvěryhodnou identitu a autorizační postup. Simulace, která vždy vrací „povoleno“, nemůže prokázat izolaci tenantů. Prokazuje pouze chování po úspěšné autorizaci.

Ověřte, že test dokáže selhat

U známé chyby spusťte nový regresní test proti chybné verzi v izolované větvi. Potvrďte, že selže ze zamýšleného důvodu. Potom použijte opravu a spusťte jej znovu.

Test, který selže kvůli nemožnosti načíst testovací data, zatím není důkazem o požadovaném chování aplikace. Prozkoumejte příčinu selhání, nejen návratový kód.

U širších změn může mutační testování pomoci posoudit, zda vybrané změny kódu způsobí selhání testů. Má své náklady a nenahrazuje kontrolu požadavků. Používejte je tam, kde další důkazy podporují důležité rozhodnutí.

Udržujte vazbu důkazů na změnu

Příslušné kontroly spouštějte na konečné revizi. Zaznamenejte vynechané kontroly a jejich důvody. Výsledek dřívějšího commitu už nemusí platit po opravě z kontroly.

Udržujte testy srozumitelné. Upřednostněte výslovnou přípravu a ověřovanou podmínku před rozsáhlou pomocnou funkcí, která důležitou podmínku skrývá. Odstraňujte nadbytečné kontroly, pokud přidávají náklady údržby, aniž odhalí jiné selhání.

Kontrolující má umět říci, co testy prokazují a co zůstává nejisté. Toto vysvětlení je užitečnější než vysoký počet testů.