Използвайте тестовете като доказателства

Започнете с изискването

Тестовете са доказателства за конкретни твърдения. Успешно изпълнение на тестове не установява всяко свойство на софтуера. Преди да поискате тестове, определете важното поведение и дефекта, който всяка проверка трябва да открива.

При измислен експорт за организация основното изискване е изолацията на данните. Потребител в организация A не трябва да получава записи от организация B. Тест, който проверява само успешно изтегляне, не установява това изискване.

Поискайте агентът да обясни връзката между изискването и проверяваното условие. Така липсващите случаи се откриват по-лесно, преди наборът от тестове да стане голям.

Изберете подходящ обхват на теста

Unit тест може бързо да провери малко преобразуване. Интеграционен тест може да провери как компонентите работят заедно. End-to-end тест може да провери важна последователност от потребителски действия през внедреното приложение или представителна негова среда.

Използвайте най-тесния обхват, който осигурява необходимите доказателства. Форматираща функция не се нуждае от пълен браузърен тест за всеки вход. Граница на правата може да изисква действителен маршрут и път за достъп до данните. Критично взаимодействие в браузъра изисква доказателства за визуализирания интерфейс.

Няма фиксирано процентно съотношение между типовете тестове, което да е подходящо за всяка система. Избирайте според неуспеха, който трябва да откриете, и разхода за поддържане на проверката.

Избягвайте общо погрешно предположение

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

Да предположим, че реализацията филтрира записите по идентификатора на организацията, подаден в заявката. Тестът използва същия идентификатор за влезлия потребител и за заявката. Той преминава успешно. Липсващият случай е потребител, който заявява идентификатора на друга организация.

Добавете този случай през действителния доверен път за идентичност и проверка на правата. Mock, който винаги връща „разрешено“, не може да установи изолация между организации. Той установява само поведението след успешно разрешаване на достъп.

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

За известен дефект изпълнете новия регресионен тест срещу дефектната версия в изолиран клон. Потвърдете, че се проваля по предвидената причина. След това приложете поправката и го изпълнете отново.

Тест, който се проваля, защото тестови данни не могат да се заредят, още не е доказателство за бизнес поведението. Прегледайте неуспеха, не само кода за изход.

При по-широки промени mutation testing може да помогне да оцените дали избрани промени в кода водят до неуспешни тестове. Този подход има разход и не заменя прегледа на изискванията. Използвайте го, когато допълнителните доказателства подкрепят решение с важни последствия.

Свържете доказателствата с промяната

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

Пазете тестовете разбираеми. Предпочитайте изрична подготовка и проверка на условието пред голяма помощна функция, която скрива важното условие. Премахвайте излишните проверки, когато увеличават поддръжката, без да откриват различен неуспех.

Проверяващият трябва да може да посочи какво установяват тестовете и какво остава несигурно. Това обяснение е по-полезно от голям брой тестове.