Започни с бизнес твърдение
„Възстановената сума не може да надхвърля полученото плащане“ е по-полезно от „тествай функцията за refund“. То определя ограничение независимо от реализацията. Назови обекта, позволената промяна и условието. Добави примери около границата, включително нула и повторни заявки при нужда. Собственикът трябва да разбира твърдението, не само разработчикът.
Не превръщай всяко старо поведение в правило
Старият софтуер показва какво става, не доказва какво трябва да става. Случайна отстъпка или прекалено отворен endpoint не стават защитено изискване само защото съществуват. Раздели наблюдаваното от одобреното намерение. При разлика запиши дали проектът пази поведението за съвместимост или го коригира съзнателно.
Свържи правилата с различни доказателства
Едно правило може да изисква проверка на изчисление, интеграционен тест за запис и тест за право на извикване. Браузърен сценарий показва потребителския път. Не използвай броя тестове като единствена мярка: десет проверки на едно предположение могат да пропуснат забранения път. Избирай доказателства срещу реалните начини за провал.
Пази смисъла при промяна на тестове
Тестовете имат нужда от поддръжка, но одобреното правило се променя само след отделно потвърждение. Прегледай причината за новите очаквания и свържи проверките с версията на правилото. Продуктовото знание и Rehearsal във Forge свързват решенията, така че зеленият резултат да остава разбираем и верен на намерението.
Определи правилото преди теста
Резервация може да се отмени само от собственика или разрешен оператор. Тест, генериран от текущия controller, може просто да повтори неговата логика за достъп. Ако тя е грешна, тестът описва дефекта убедително. Започни от одобрено бизнес правило и независими примери.
Уточни кой действа, върху кой обект и в какво състояние. Добави разрешен случай, забранен случай и граница като вече отменена резервация. Свържи произхода на правилото и решението на собственика. Тестът става превод на намерението в доказателство, а не източник на самото намерение.
| Решение | Полезно изискване | Доказателство |
|---|---|---|
| Участник | Само разрешени роли отменят. | Разрешена и отказана сесия. |
| Обект | Резервацията е в разрешения обхват. | Чужд клиент и чужд офис. |
| Повторение | Повторното събитие няма втори ефект. | Повторение със същия идентификатор. |
Къде възникват грешките
Собственикът може да одобри умишлена промяна, но решението трябва да се различава от опит на Разработчик да направи неуспешен тест зелен. Запази старото правило и доказателствата. Провери кои други проекти и версии зависят от него, преди да го приемеш за локално към един екран.
Тестът доказва правило; не е правомощието, което го измисля.
Превърни го в работен списък
- Пиши разбираеми за собственика ограничения.
- Раздели наблюдаваното и желаното.
- Включи забранени и гранични случаи.
- Проверявай промените в очакванията.
Конкретна следваща стъпка
Създай карта на правилото с формулировка, собственик, обхват, примери и сценарии. Непознатото поведение остава въпрос до потвърждение. Това е по-полезно от огромен набор тестове с непрегледани очаквания.
Гледай свързан казус
Език на аудиото: английски
Видеото не може да се зареди. Опитай отново по-късно.