fix(tests): use os.utime for deterministic mtime in phase1 completion tests#41
Conversation
… tests Replace fragile 'time.time() - 2' hack with explicit os.utime() calls that set file mtimes deterministically relative to the captured start time. Artifacts expected to be stale get mtime = start - 60; fresh files get mtime = start + 60. This eliminates mtime granularity races on WSL and other virtualized filesystems where st_mtime may have coarser resolution than time.time().
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR enhances two test functions in ChangesPhase Completion Test Timestamp Control
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Coverage Report
Generated by pytest-cov on |
Problem
test_phase1c_accepts_fresh_sandbox_state_with_existing_notesfails on WSL becausetime.time()has microsecond precision while filesystemst_mtimemay be truncated to coarser granularity. Files created afterrun_start = time.time()can havest_mtime < run_start, causing_path_is_fresh()to returnFalse.The sister test
test_phase1_check_patches_notes_root_and_sandbox_planused a fragiletime.time() - 2workaround with the same root cause.Fix
Replace timestamp arithmetic with explicit
os.utime()calls that set deterministic mtimes relative to the captured start time:os.utime(..., (run_start - 60, run_start - 60))os.utime(..., (run_start + 60, run_start + 60))This eliminates all dependence on filesystem clock granularity, platform differences, and test execution speed.
Testing
Summary by CodeRabbit