Skip to content

test(predict-pv-power): delete fixture attrs on restore instead of setting None - #4378

Open
chalfontchubby wants to merge 1 commit into
springfall2008:mainfrom
chalfontchubby:fix/predict-pv-power-test-fixture-restore
Open

test(predict-pv-power): delete fixture attrs on restore instead of setting None#4378
chalfontchubby wants to merge 1 commit into
springfall2008:mainfrom
chalfontchubby:fix/predict-pv-power-test-fixture-restore

Conversation

@chalfontchubby

Copy link
Copy Markdown
Collaborator

Summary

Follow-up to #4374 (merged) - a Copilot review comment landed after the merge, flagging a real fixture-hygiene bug in the new regression test:

The fixture-restore logic can leave my_predbat.load_minutes_step, load_minutes_step10, or prediction set to None when those attributes didn't exist before this test (e.g. load_minutes_step* aren't initialised in PredBat.reset()). That mutates the shared my_predbat fixture into an invalid state for later tests that expect dict/Prediction objects, and can cause order-dependent failures.

Verified directly: load_minutes_step/load_minutes_step10 are only ever set at the end of a real update_pred() cycle (predbat.py:1114-1115), and self.prediction is only ever assigned when a real Prediction object gets constructed (plan.py:1080) - neither exists on a freshly-created test fixture before this test runs. The finally block's getattr(..., None) + unconditional restore left them present-but-None afterwards, worse than the original missing-attribute state.

Change

Track attribute presence up front (hasattr), and on restore, delattr rather than assign None for any attribute that didn't exist beforehand - matching what a genuinely fresh fixture would look like.

Test plan

  • unit_test.py --test predict_pv_power - passes
  • unit_test.py --quick - full suite passes, no order-dependent failures
  • pre-commit clean

🤖 Generated with Claude Code

…tting None

load_minutes_step/load_minutes_step10/prediction aren't set until a
real update_pred() cycle or calculate_plan() runs, so on a fresh
my_predbat fixture they may not exist as attributes at all. The
finally-block restore was unconditionally assigning the captured
(possibly None) value back, which left them present-but-None when they
hadn't existed before - worse than the original missing-attribute
state, and can cause order-dependent failures in later tests that
expect a dict/Prediction object or use hasattr() to guard access.

Track presence up front and delete the attribute on restore when it
was absent to begin with, matching what a later test would actually
see on a truly fresh fixture (Copilot review finding on springfall2008#4374, merged
before the review landed).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant