Chrono Mock值得測試的日期
軟體不會在普通的星期二出問題。它出問題的時候是季度的最後一天、2 月 29 日、一年翻篇的那一刻，以及授權到期後的一秒鐘。這些日期能找出那些錯誤——其中 14 個以具名情境的形式內建。
週期邊界
凡是要結算一個週期、依年份為單據編號、或是計提到某個截止日的功能，最先在這些日期上出錯。
- 月底最後一天——月底結帳與期間計提在當月的最後一天表現正常嗎？
- 季底最後一天——季底結帳與報表在當季的最後一天表現正常嗎？
- 會計年度最後一天——應用程式會不會在正確的那一天結束會計年度，也就是新會計年度開始的前一天？
- 跨年，即時發生——單據編號、名稱中的年份與年度報表，能否在跨年的過程中正確處理，而不是事後重新啟動才恢復？
最後一項通常是人們根本無法測試的，因為這需要時鐘在應用程式執行期間越過 12 月 31 日的午夜。用加速的時鐘，這只是十秒鐘的事。
日曆與表示形式的邊緣
- 2 月 29 日——四年才有一次的閏日，數量驚人的驗證程式碼會直接拒絕它。
- Unix 紀元零點——應用程式把 1970 年 1 月 1 日當作一個真實的日期，還是當作一個本該拒絕儲存的空值？
- 2038 年邊界——有號 32 位元
time_t耗盡的時刻，即2038-01-19T03:14:07Z。再過一秒，計數器就會溢位回到 1901 年。
授權、試用期與安裝
它們是用來測試你自己的授權機制的，這也正是撰寫它們的初衷。
- 試用期最後一天——在試用期的最後一刻，應用程式還能正常運作嗎？
- 試用期結束後的第一天——試用一結束它就拒絕存取了嗎？拒絕的方式如何？是一則合理的提示，還是一堆堆疊追蹤？
- 授權一年前已過期——它能處理早就過期的授權嗎，而不只是昨天剛過期的？
- 早於安裝日期的日期——當時鐘被設到應用程式自己的安裝日期之前，它的表現如何？這一項讀取的是目標程式自己的檔案日期，所以不需要參數。
商業規則與時鐘行為
- 付款到期，+N 個工作日——N 個工作日後到期的付款，能否落在正確的那一天，跳過週末與相應國家的假日？這是唯一需要日曆的情境，而且不同市場的答案不同。
- 成年年齡的邊界——應用程式會接納恰好到達邊界的人，並拒絕差一天的人嗎？
- 時鐘偏差，+90 s——當應用程式的時鐘比真實時間快九十秒時，它還能應對嗎？以時間為基礎的一次性密碼與權杖驗證就是在這種情形下失效的。
如何使用
一個情境就是一個具名的日期運算式。計算機會算出它的意義，替換則讓應用程式在該時刻執行——兩處使用的是同一個名稱。
# 現在是哪一天，這一天測試的是什麼？ 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
在視窗裡，它們是日期輸入欄上方的一排小標籤——點一下就會填入。每一個都附帶一句話，說明它能抓到什麼問題，而這正是線上日期計算機無法提供的部分。
這裡沒有的內容
日光節約時間的切換。讓應用程式經歷春季撥快或秋季撥慢的邊界，是一項真正有用的測試，而它刻意缺席，因為工作階段時區是沒有日光節約時間的固定偏移量——目前沒有可模擬的切換。內建一個悄悄什麼都不做的情境，比不內建更糟。
等到有了時區規則的模型，它就會回來。 時區能做什麼、不能做什麼 →