【要約】10 years ago, someone wrote a test for Servo that included an expiry in 2026 [Hacker_News] | Summary by TechDistill

> Source: Hacker_News

// Discussion Topic

テストコードにおける「時間」の扱い。ハードコードによる期限切れ問題、時間のパッチによる副作用、および決定論的なテスト環境を構築するための抽象化手法と設計パターン。

// Community Consensus

日付のハードコードは「その場しのぎ」であり、避けるべきである。推奨されるのは、TimeProvider等のインターフェースを用いた依存性の注入（DI）である。また、テストの不安定性（Flakiness）は、実装やテストの境界条件の欠陥を示す重要なシグナルであり、軽視すべきではないという強い合意がある。ランダム性の導入については、CIの安定性を損なわないよう、シード値を用いた決定論的なプロパティベーステストとして扱うべきであるとの見解が示されている。

// Alternative Solutions

Goの`synctest`（決定論的な時間制御）、.NETの`TimeProvider`、Javaの`InstantSource`、Rubyの`timecop`、Rustの`mock_instant`、およびプロパティベーステスト（Hypothesis等）を用いたエッジケースの探索。

// Technical Terms

Senior Engineer Insight

> 本議論は、我々のシステム開発においても極めて示唆に富む。特に「時間の抽象化」を怠ることは、将来的な非決定的なバグや、再現困難なFlaky Testを量産するリスクを孕む。大規模なトラフィックを扱う現場では、テストの不安定性は開発サイクルを停滞させる致命的な要因となる。\n\n我々が取るべき指針は明確だ。時間の取得を直接的なシステムコールに依存させず、必ずインターフェースを介して注入する設計を徹底すること。また、議論にあった「Feature Flagへの有効期限設定」は、技術的負債の蓄積を自動的に検知する極めて優れた運用戦略である。単なるコードの書き方ではなく、負債を管理する「仕組み」として、これらの知見を設計プロセスに組み込むべきである。