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

Почнете со барањето

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

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

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

Изберете соодветен опфат на тестот

Единичен тест може брзо да провери мала преобразба. Интеграциски тест може да провери како компонентите работат заедно. Тест од почеток до крај може да провери важна низа кориснички дејства низ распоредена или репрезентативна апликација.

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

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

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

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

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

Додајте го тој случај преку вистинската патека за доверлив идентитет и авторизација. Имитација што секогаш враќа „дозволено“ не може да ја потврди изолацијата меѓу закупците. Го потврдува само однесувањето по успешна авторизација.

Проверете дали тестот може да биде неуспешен

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

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

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

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

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

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

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