68c66a0ff3* Fix options flow changes being silently discarded for UI-configured entries
validate() merges config_entry.options then config_entry.data, on the
assumption that data only ever holds YAML-imported settings (which should
win) or, for UI-created entries, just the entry name (harmless to apply
last).
That assumption doesn't hold for entries created before data/options were
split: their data still carries the full settings snapshot from initial
setup. Applying it after options means any change made through the options
flow for a key that already exists in data (e.g. adding a light) is
silently ignored, even though the options flow reports success and the
entry reloads without error.
Reproduced on a real entry: added a light via the options flow, entry
reloaded cleanly, but the light was never picked up by the switch's
service-call interceptor ("No switch found for entity_id=...") because
data still held the old light list and clobbered the updated options.
Fix: only let data win over options for genuinely YAML-imported entries
(config_entry.source == SOURCE_IMPORT), matching the existing use of that
check elsewhere in this file. For UI-configured entries, apply options
last so changes made through the options flow actually take effect.
* Add focused tests for the data/options merge order in validate()
Covers both source-specific contracts the merge logic relies on, per
review feedback on this PR:
- SOURCE_USER: options must win over data (this PR's actual fix - proven
to fail against the pre-fix code, verified locally by reverting
switch.py and re-running).
- SOURCE_IMPORT: data must keep winning over options (the existing,
intentional YAML-precedence behavior - unchanged by this PR, verified
to already pass against the pre-fix code too).
Verified against a real Home Assistant instance's test harness
(pytest-homeassistant-custom-component + the actual installed
homeassistant package), not just reasoned about statically.
---------
Co-authored-by: Bas Nijholt <bas@nijho.lt>
|
||
|---|---|---|
| .. | ||
| __init__.py | ||
| conftest.py | ||
| README.md | ||
| test_adaptation_utils.py | ||
| test_color_and_brightness.py | ||
| test_config_flow.py | ||
| test_hass_utils.py | ||
| test_init.py | ||
| test_switch.py | ||
Developer notes for the tests directory
To run the tests, check out the CI configuration to see how they are executed in the CI pipeline. Alternatively, you can use the provided Docker image to run the tests locally or run them with VS Code directly in the dev container.
Prerequisites
Before running tests with Docker, you need a local Home Assistant core checkout with symlinks:
# Clone HA core (one-time setup)
git clone --depth 1 https://github.com/home-assistant/core.git core
# Setup symlinks (one-time setup)
./scripts/setup-symlinks
Running tests with Docker
Navigate to the adaptive-lighting repo folder and execute the following command.
Important: Mount the entire repo (-v $(pwd):/app), not individual directories, or the symlinks will break.
Linux / MacOS / Windows PowerShell:
docker run -v ${PWD}:/app basnijholt/adaptive-lighting:latest
- In windows command prompt, the command is:
docker run -v %cd%:/app basnijholt/adaptive-lighting:latest
This command will download the Docker image from the adaptive-lighting Docker Hub repo and run the tests.
If you prefer to build the image yourself, use the following command:
docker build -t basnijholt/adaptive-lighting:latest --no-cache --progress=plain .
This might be necessary if the image on Docker Hub is outdated or if the test_dependencies.py file is updated.
Passing arguments to pytest
You can pass arguments to pytest by appending them to the command:
For example, to run the tests with a custom log format, use the following command (this also gets rid of the captured stderr output):
docker run -v $(pwd):/app basnijholt/adaptive-lighting:latest --show-capture=log --log-format="%(asctime)s %(levelname)-8s %(name)s:%(filename)s:%(lineno)s %(message)s" --log-date-format="%H:%M:%S" tests/components/adaptive_lighting/