Во оваа статија
Главната идеја
Највредниот тест објаснува правило што не смееме случајно да го прекршиме и покажува јасен пример за очекуваното однесување.
Копчето работи, формуларот се отвора и апликацијата изгледа подготвена. Сепак, вистинскиот проблем може да се појави кога двајца корисници ја менуваат истата нарачка или кога некој се обидува да одобри документ без потребната улога.
Тестирањето на деловен софтвер треба да ги следи последиците од грешката. Бројот на тестови е помалку корисен показател од одговорот на прашањето: кои важни правила ќе ги забележиме ако престанат да важат?
Претворете го правилото во пример
Да земеме резервација на залиха. Ако на располагање има пет парчиња, а корисникот бара шест, системот треба да го примени договореното правило: одбивање, делумна резервација или дозволена дополнителна набавка. Прво мора да се договори кое однесување е правилно.
Тестот потоа го опишува почетниот податок, дејството и очекуваниот резултат. Името може да биде реченица што ја разбира и колега што не програмира: „Нарачка со недоволна залиха останува на проверка“.
Додадете пример со точно пет парчиња и пример без достапна залиха. Граничните случаи често го разјаснуваат значењето на правилото подобро од општ опис.
Проверувајте на соодветното ниво
Пресметка или дозволен премин меѓу статуси може да се провери блиску до деловната логика. Зачувувањето на поврзани записи бара проверка и со базата. На корисничкото ниво вреди да се проверат неколку клучни текови од почеток до крај.
На пример, целосен тест може да создаде нарачка, да ја одобри со соодветна улога и да потврди дека се појавува во листата за подготовка. Тој не мора да ја повторува секоја комбинација што веќе е проверена во пресметките.
Така секој тест добива јасна задача. Кога ќе се појави грешка, тимот полесно разбира дали проблемот е во правилото, зачувувањето или поврзувањето на екраните.
Вклучете ги неуспешните патеки
Проверете што се случува кога корисникот нема дозвола, кога врската со надворешен систем е прекината или кога барањето е повторено. Интерфејсот треба да ја покаже состојбата, а системот да остане доследен на договорените правила.
Ако операцијата има повеќе чекори, договорете што се враќа назад при неуспех и што останува за подоцнежна обработка. Тестот треба да провери и дека не е направена несакана промена. Неуспешно одобрување, на пример, не треба тивко да испрати порака дека документот е одобрен.
Користете синтетички податоци што ги претставуваат реалните случаи. Нема потреба тестовите да содржат вистински имиња, контакти или деловни документи на клиенти.
Чувајте ги тестовите разбирливи
При промена на правило, прегледајте ги примерите со лицето што го познава процесот. Дали старото очекување се менува намерно или новиот код случајно го прекршува? Оваа разлика треба да биде видлива во описот на промената.
Кога ќе се најде грешка во употреба, додадете проверка за причината ако таа штити важно однесување. Избегнувајте проверки што само ја копираат внатрешната структура на кодот: тие може да бараат многу одржување без да откриваат корисни проблеми.