ESPSomfy-RTS/test/e2e
cjkas 97d8a90da8 fix: review findings on the token key
- Load the token key in Web::startup(), before either web server starts,
  so no token can be made with the all-zero key; log a failed
  pref.begin().
- createAPIToken checks mbedtls' return codes. On a failure it leaves
  the token empty, which tokenMatches never accepts, instead of hex
  from uninitialised stack.
- API_TOKEN_SIZE in ApiToken.h replaces the five char[65] buffers; the
  HMAC's description moves to createAPIToken, with the None form.
- handleLogin builds the candidate token once and compares it once.
- e2e: the serverId test skips on `secured` like its neighbours, names
  its values, and says it assumes the device sees this PC's address.
- KNOWN_ISSUES keeps #81, which #108 removes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-27 20:39:08 +01:00
..
conftest.py feat: throttle failed logins per client IP 2026-10-26 22:08:30 +01:00
proto_client.py test: start the e2e suite for socket protocol 2 2026-10-24 11:03:07 +02:00
README.md feat: throttle failed logins per client IP 2026-10-26 22:08:30 +01:00
test_auth.py fix: review findings on the token key 2026-10-27 20:39:08 +01:00
test_commands.py feat: command ops for socket protocol 2 2026-10-24 13:42:41 +02:00
test_edits.py fix: edit ops second review findings 2026-10-24 18:29:34 +02:00
test_messages.py fix: protocol 2 core review findings 2026-10-24 13:17:15 +02:00
test_settings.py fix: deletes send their removal after the reply; test_reboot waits for the restart 2026-10-25 13:07:17 +01:00
test_survival.py test: survival tests skip while a web UI tab holds a socket slot 2026-10-25 21:21:05 +01:00
test_sync.py test: sync_waits_for_next lets events through 2026-10-24 13:40:08 +02:00

e2e suite

Runs against a real device on your network, by hand, never in CI. It checks socket protocol 2 (PROTOCOL.md) and that the device survives the loads that used to run its heap out.

~/.platformio/penv/Scripts/uv run --no-project --with pytest -- pytest test/e2e --device 192.168.1.120
Option Use
--device the device's address (required)
--password, --username / --pin the credentials of a Secured device
--radio --shade <id> also send real commands: that shade moves a little and back
--edit also add a room and delete it again
--reboot also reboot the device and wait for it to come back
--lockout on a Secured device, also fail /login until this PC is refused, then wait out the 30 s lockout
--record save hello, the sync and the schema to test/fixtures/proto2/, for the web UI and Home Assistant tests

A plain run sends nothing on air, changes no setting (it saves only values the device already has) and doesn't reboot the device. The command tests send ops that are refused before they reach the radio, and one setPositions that sets a shade to the position the sync gave: that drops the fraction of a percent the shade's believed position may have had. The edit tests send edits that are refused, and one shade sort order set to the order it has, which saves the shades again unchanged. The settings tests send saves that are refused, and one that saves the NTP server and time zone the device already has. The frequency scan test pauses the radio's sending for a second or two, as a scan does. It does fill every socket slot for a few seconds, and replays a page load.

The web UI holds one of the device's 5 socket slots for each open tab. The tests that fill every slot skip while one is taken, so close the UI's tabs before a run.

The tests run in whatever security mode the device is in; the suite never changes it. To test both modes, run the suite once in each.