Summary
All current test configs pin days_per_period to 365, which means the new config-driven seasonal/storage/ramping scaling logic introduced in #264 is only exercised at a single value.
Task
Add at least one test database fixture that uses a non-365 value for days_per_period (e.g., 7 for a representative week, or 14 for a representative two-week period) to catch regressions in the new config-based path.
Acceptance Criteria
- Add a new test database (SQL fixture) configured as a representative week (
days_per_period = 7) and/or representative two-week period (days_per_period = 14).
- Add a corresponding test config TOML file that sets
days_per_period to the non-365 value.
- Ensure existing tests continue to pass and new tests run against both the original 365-day and the new non-365 fixture.
- The fixture should specifically exercise the seasonal/storage/ramping constraint scaling logic.
Background
This was identified during the review of PR #264 (Rework the definition of seasons), in the comment: #264 (comment)
Requested by @idelder.
Summary
All current test configs pin
days_per_periodto365, which means the new config-driven seasonal/storage/ramping scaling logic introduced in #264 is only exercised at a single value.Task
Add at least one test database fixture that uses a non-365 value for
days_per_period(e.g.,7for a representative week, or14for a representative two-week period) to catch regressions in the new config-based path.Acceptance Criteria
days_per_period = 7) and/or representative two-week period (days_per_period = 14).days_per_periodto the non-365 value.Background
This was identified during the review of PR #264 (Rework the definition of seasons), in the comment: #264 (comment)
Requested by @idelder.