Chrono Mockテストする価値のある日付
ソフトウェアは、ごく普通の火曜日には壊れません。四半期の最終日、2 月 29 日、年が変わる瞬間、そしてライセンスが切れた 1 秒後に壊れます。そうしたバグを見つけるのがこれらの日付で、そのうち 14 件が名前付きシナリオとして同梱されています。
期間の境界
期間を締める処理、書類に年で番号を振る処理、締め日まで計上する処理は、まずここで間違えます。
- 月末日 - 月次の締め処理と期間計上は、月の最終日に正しく動くか。
- 四半期の最終日 - 四半期の締め処理とレポートは、四半期の最終日に正しく動くか。
- 会計年度の最終日 - アプリは会計年度を正しい日、つまり次の会計年度が始まる前日に締めるか。
- 年越しの瞬間 - 書類番号、名前に含まれる年、年次レポートは、年が変わるその最中に正しく処理されるか。あとから再起動されるのではなく。
最後のものは、多くの人がまったくテストできないものです。アプリが動いている間に時計が 12 月 31 日の午前 0 時をまたぐ必要があるからです。加速した時計を使えば、10 秒の作業です。
暦と表現の端
- 2 月 29 日 - 4 年に 1 度しかないうるう日で、驚くほど多くの検証コードが頭から拒否します。
- Unix エポックのゼロ - アプリは 1970 年 1 月 1 日を実在する日付として扱うか、それとも保存を拒否すべき空の値として扱うか。
- 2038 年の境界 - 符号付き 32 ビットの
time_tが尽きる瞬間、2038-01-19T03:14:07Z。その 1 秒後にカウンターは桁あふれして 1901 年に戻ります。
ライセンス、試用期間、インストール
これらは自社のライセンス機構をテストするためのもので、そのために書かれました。
- 試用期間の最終日 - 試用期間のまさに最後の瞬間でも、アプリは動くか。
- 試用期間終了後の初日 - 試用期間が終わった瞬間にアクセスを拒否するか。その場合どのように拒否するか。分かりやすいメッセージか、それともスタックトレースか。
- 1 年前に期限切れになったライセンス - 昨日だけでなく、ずっと前に期限切れになったライセンスを正しく扱えるか。
- インストール前の日付 - 時計が自身のインストール日より前に設定されたとき、正しく動作するか。これは対象自身のファイルの日付を読むので、パラメーターは不要です。
業務ルールと時計の挙動
- 支払期日、+N 営業日 - N 営業日後が期日の支払いは、週末とその国の祝日を飛ばして正しい日に着地するか。カレンダーを必要とする唯一のシナリオで、答えは市場によって異なります。
- 成年年齢の境界 - ちょうど境界にいる人を受け入れ、1 日足りない人を断れるか。
- 時計のずれ、+90 秒 - アプリの時計が実時間より 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
ウィンドウでは、日付欄の上にチップとして並んでいて、ワンクリックで入力されます。それぞれが「何を捕まえるのか」を説明する一文を持っています。オンラインの日付電卓では得られない部分です。
ここに含まれないもの
夏時間の切り替え。アプリを夏時間の開始・終了の境界で動かすことは本当に役立つテストですが、意図的に含めていません。セッションのタイムゾーンは夏時間のない固定オフセットなので、再現できる切り替えがまだ存在しないためです。黙って何もしないシナリオを出荷するくらいなら、出荷しないほうがましです。
タイムゾーン規則のモデルとともに戻ってきます。タイムゾーンができることとできないこと →