Користите тестове као доказе

Почните од захтева

Тестови су докази за конкретне тврдње. Успешно извршавање тестова не потврђује свако својство софтвера. Пре него што затражите тестове, одредите важно понашање и грешку коју свака провера треба да открије.

Код измишљеног извоза података организације главни захтев је изолација података. Корисник из организације A не сме да добије записе организације B. Тест који проверава само успешно преузимање не потврђује овај захтев.

Затражите да агент објасни везу између захтева и провере у тесту. Тако ћете лакше открити случајеве који недостају пре него што скуп тестова постане велики.

Изаберите одговарајући опсег теста

Јединични тест може брзо да провери малу трансформацију. Интеграциони тест може да провери како компоненте раде заједно. End-to-end тест може да провери важан низ корисничких радњи кроз постављену или репрезентативну апликацију.

Користите најужи опсег који даје потребне доказе. Алату за форматирање није потребан потпун тест у прегледачу за сваки улаз. Граница ауторизације може да захтева стварну руту и путању приступа подацима. За критичну интеракцију у прегледачу потребни су докази о приказаном интерфејсу.

Ниједан фиксни однос врста тестова не одговара сваком систему. Бирајте према отказу који треба да откријете и трошку одржавања провере.

Избегните заједничку погрешну претпоставку

Агент може да напише имплементацију и тестове на основу истог неспоразума. Они могу да се слажу, а да захтев остане неиспуњен.

Претпоставимо да имплементација филтрира записе по ID вредности организације наведеној у захтеву. Тест користи исти ID за пријављеног корисника и захтев. Тест пролази. Недостаје случај у коме корисник тражи ID друге организације.

Додајте тај случај кроз стварну путању поузданог идентитета и ауторизације. Mock који увек враћа „дозвољено” не може да потврди изолацију клијентских организација. Потврђује само понашање после успешне ауторизације.

Проверите да тест може да падне

За познату грешку покрените нови регресиони тест на неисправној верзији у изолованој грани. Потврдите да не пролази из намераваног разлога. Затим примените исправку и поново га покрените.

Тест који пада зато што не може да учита припремљене тестне податке још није доказ о пословном понашању. Испитајте узрок пада, а не само излазни код.

За обимније промене мутационо тестирање може да помогне да процените да ли одабране промене кода изазивају пад тестова. Оно има трошак и не замењује преглед захтева. Користите га тамо где додатни докази подржавају одлуку са значајним последицама.

Повежите доказе са променом

Покрените релевантне провере на коначној ревизији. Забележите прескочене провере и разлоге. Резултат ранијег commit записа можда више не важи после исправке током прегледа.

Нека тестови буду разумљиви. Дајте предност изричитој припреми и провери у односу на велику помоћну функцију која скрива важан услов. Уклоните сувишне провере када повећавају трошак одржавања, а не откривају другачији отказ.

Особа која прегледа промену треба да уме да наведе шта тестови доказују и шта остаје неизвесно. То објашњење је корисније од великог броја тестова.