Repository navigation
fix(frontend): make the trial subscription summary test clock-independent - #215
Merged
Merged
Conversation
…dent The test built its trial end with setDate(+7), which is 7 days + 1 hour away when the window crosses the US DST fall-back (2026-11-01). The code rounds up elapsed time, so it returned 8 in America/New_York from 2026-10-25. Freeze the clock with fake timers and use exact 24h offsets; the product code is correct.
Security Scan Results: PASSED
|
PR Checks Summary
✅ All checks passed! Ready for review. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
getSubscriptionSummary › should create summary for trial subscriptionstarted failing on main from 2026-10-25 (Expected 7, received 8) under TZ America/New_York.Cause
The test built the trial end with
setDate(getDate() + 7). In America/New_York the DST fall-back is 2026-11-01, so from 2026-10-25 that is 7 days + 1 hour of elapsed time.BillingCycleCalculator.calculateTrialDaysRemainingrounds elapsed time up, so it returned 8. The product code is correct; the test depended on the wall clock and local timezone.Fix
Test only. The case now freezes the clock with
jest.useFakeTimers().setSystemTime(...)(real timers restored inafterEach) and uses an exact 7 x 24h offset. The assertion (trialDaysRemaining === 7) is unchanged. It runs against three fixed clocks, including 2026-10-25T01:28Z, the one that failed.Verification
Coverage note (not changed here)
The "global coverage threshold not met" lines in the failing run come from
bail: process.env.CI ? 1 : 0infrontend/jest.config.js: jest stopped after the first failure (66 of 710 suites ran), so coverage was only 7%. Not a real regression.