mirror of
https://github.com/esphome/esphome.git
synced 2026-09-11 15:27:33 +00:00
J. Nick Koston
f06e96685b
The previous implementation extended `track_yaml_loads` across the entire validation pass to catch deferred `!include` and package loads, but that also captured framework YAML loaded internally by component validators (e.g. LVGL's `hello_world.yaml`) and produced spurious "unresolved substitution" warnings during the pre-validation force-load. bundle.py already had the right pattern: a fresh post-validation re-parse plus `force_load_include_files`. - Lift the discovery into `yaml_util.discover_user_yaml_files` and have both `bundle.py` and `config.py` use it (DRY). - Capture `secrets.yaml` / `secrets.yml` by the *un-resolved* listener fname so a `secrets.yaml` symlinked to a non-secrets-named target is still flagged for redaction. - Add a `warn_on_unresolved` flag to `force_load_include_files` so the discovery path (where substitutions haven't run) logs at debug instead of warning. - Reject `store_yaml` configs with an unencrypted API via `FINAL_VALIDATE_SCHEMA`; an explicit `allow_unencrypted: true` opt-out keeps lab setups working (renamed from `allow_unencrypted_api` so the integration-test harness's naive `api:` string replacement doesn't clobber it). - Annotate `store_yaml_chunk_buf` with the `cppcoreguidelines-avoid-non-const-global-variables` suppression that matches other intentional API-side globals. - Update unit tests to exercise the new `DiscoveredYamlFiles` shape plus a symlink-secrets case.
Tests for ESPHome
This directory contains some tests for ESPHome.
At the moment, all the tests only work by simply executing
esphome over some YAML files that are made to test
whether the yaml gets converted to the proper C++ code.
Of course this is all just very high-level and things like unit tests would be much better. So if you have time and know how to set up a unit testing framework for python, please do give it a try.
When adding entries in test_.yaml files we usually need only
one file updated, unless conflicting code is generated for
different configurations, e.g. wifi and ethernet cannot
be tested on the same device.
Current test_.yaml file contents.
| Test name | Platform | Network | BLE |
|---|---|---|---|
| test1.yaml | ESP32 | wifi | None |
| test2.yaml | ESP32 | ethernet | esp32_ble_tracker |
| test3.yaml | ESP8266 | wifi | N/A |
| test4.yaml | ESP32 | ethernet | None |
| test5.yaml | ESP32 | wifi | ble_server |
| test6.yaml | RP2040 | wifi | N/A |
| test7.yaml | ESP32-C3 | wifi | N/A |
| test8.yaml | ESP32-S3 | wifi | None |
| test10.yaml | ESP32 | wifi | None |