Даты, которые стоит тестировать
Программы не ломаются в обычный вторник. Они ломаются в последний день квартала, 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
В окне это чипы над полем даты — один щелчок заполняет его. У каждого есть своя фраза о том, что он ловит, а этого онлайн-калькулятор дат дать вам не может.
Чего здесь нет
Переходов на летнее и зимнее время. Проведение приложения через границу перехода вперёд или назад — по-настоящему полезный тест, и он намеренно отсутствует, потому что часовой пояс сессии — это фиксированное смещение без летнего времени: пока нет перехода, который можно было бы смоделировать. Поставлять сценарий, который тихо ничего бы не делал, было бы хуже, чем не поставлять его.
Он вернётся вместе с моделью правил часовых поясов. Что часовой пояс делает и чего не делает →