Chrono MockДати, які варто тестувати
Програмне забезпечення не ламається в звичайний вівторок. Воно ламається в останній день кварталу, 29 лютого, у мить зміни року й за секунду після спливу ліцензії. Ось дати, що знаходять такі помилки, — 14 із них постачаються як іменовані сценарії.
Межі періодів
Усе, що закриває період, нумерує документ за роком або нараховує до відсікання, помиляється тут першим.
- Останній день місяця — чи правильно поводяться закриття місяця й нарахування за період в останній день місяця?
- Останній день кварталу — чи правильно поводяться закриття кварталу й звітність в останній день кварталу?
- Останній день фінансового року — чи закриває застосунок фінансовий рік у правильний день, напередодні початку нового фінансового року?
- Зміна року наживо — чи впорається нумерація документів, рік у назві й річна звітність зі зміною року в момент, коли вона відбувається, а не перезапускаються потім?
Останній випадок зазвичай узагалі неможливо перевірити, бо для нього потрібно, щоб годинник перетнув північ 31 грудня, поки застосунок працює. З прискореним годинником це робота на десять секунд.
Межі календаря й подання
- 29 лютого — високосний день, що буває раз на чотири роки й який дивовижна кількість коду перевірки просто відкидає.
- Нульова епоха Unix — чи вважає застосунок 1 січня 1970 року справжньою датою, чи порожнім значенням, яке він мав відмовитися зберігати?
- Межа 2038 року — момент, коли закінчується знаковий 32-розрядний
time_t:2038-01-19T03:14:07Z. За секунду лічильник переповнюється й переходить у 1901 рік.
Ліцензії, пробні періоди й встановлення
Вони призначені для тестування вашого власного ліцензування — саме для цього їх і написано.
- Останній день пробного періоду — чи працює застосунок у найостаннішу мить пробного періоду?
- Перший день після закінчення пробного періоду — чи відмовляє він у доступі саме в момент закінчення пробного періоду і як? Розумним повідомленням чи стеком викликів?
- Ліцензія сплила рік тому — чи впорається він із ліцензією, що сплила давно, а не лише вчора?
- Дата до встановлення — як він поводиться, коли годинник виставлено раніше за дату його власного встановлення? Цей сценарій читає дату файлу самої цілі, тож параметр не потрібен.
Бізнес-правила й поведінка годинника
- Строк платежу, +N робочих днів — чи припадає платіж зі строком через N робочих днів на правильний день, з пропуском вихідних і свят потрібної країни? Єдиний сценарій, якому потрібен календар, і відповідь різниться між ринками.
- Межа повноліття — чи пускає застосунок людину рівно на межі й чи відмовляє тій, кому бракує одного дня?
- Розбіжність годинника, +90 с — чи впорається застосунок, коли його годинник іде на дев’яносто секунд попереду справжнього часу? Саме цей випадок ламає одноразові паролі на основі часу й перевірку токенів.
Як користуватися сценарієм
Сценарій — це іменований вираз для дати. Калькулятор обчислює, що він означає, а підміна запускає застосунок із цією датою — те саме ім’я в обох місцях.
# Яка це дата і що ця дата перевіряє? chrono calc --preset month-end # Запустити застосунок із нею chrono run "C:\apps\test.exe" --preset year-rollover --report session.txt # Сценарії пробного періоду беруть дату початку з дати файлу самої цілі chrono run "C:\apps\test.exe" --preset trial-first-day-after
У вікні це чипи над полем дати — один клік заповнює його. Кожен має власне речення про те, що він ловить, а цього онлайн-калькулятор дат дати вам не може.
Чого тут немає
Переходів на літній і зимовий час. Проведення застосунку через межу переходу вперед або назад — справді корисний тест, і він навмисно відсутній, бо часовий пояс сесії — це фіксоване зміщення без літнього часу: поки немає переходу, який можна було б змоделювати. Постачати сценарій, що тихо нічого б не робив, було б гірше, ніж не постачати його.
Він повернеться разом із моделлю правил часових поясів. Що часовий пояс робить і чого не робить →