Implement IO-1 (Fresh install / first boot) and IO-2 (Idempotent restart)
acceptance tests for the hardware-free install and onboarding journey.
IO-1 validates:
- Fresh install starts with empty data volume
- First-run setup is accessible before PIN configuration
- PIN setup completes successfully
- Migrations run (detected in logs)
- PIN persists after setup
- Health check returns green
- No nodes are attached on fresh install
IO-2 validates:
- Configured install (PIN, node, zone) persists across restart
- Same data directory is reused after restart
- No re-setup prompt appears after restart
- Node label and position persist correctly
- Zone configuration persists correctly
- Mothership remains healthy after restart
These tests complete the IO-1..IO-11 acceptance test suite as specified
in docs/plan/plan.md, enabling hardware-free CI validation of the
installation and onboarding journey.
Closes: bf-2hi0h
Implements acceptance tests for failure scenarios and edge cases during
node onboarding per the plan specification:
- IO-7: Provisioning timeout - node that goes silent is marked offline
within heartbeat window (60s) and surfaced in /api/fleet; no crash
- IO-8: Bad/expired token - invalid token rejected with clear error;
node never enters fleet; no zombie row
- IO-9: Duplicate MAC - second connection with same MAC handled
(disconnects first or rejects second); no duplicate rows
- IO-10: Drop mid-onboard - killing simulator during onboarding leaves
node re-onboardable; no half-provisioned lock
- IO-11: Firmware-version skew - old firmware nodes onboard successfully
and OTA can be initiated
Tests use the acceptance harness with spaxel-sim and verify proper
handling of each scenario without mothership crashes or data corruption.
Closes: bf-1922s
Implements IO-6: Full new-user E2E (happy path) — HARD GATE.
The test verifies the complete onboarding journey from fresh install
to live events:
1. Fresh install + PIN setup
2. 6-node fleet onboarding via spaxel-sim
3. Define 2 zones + 1 portal
4. Run walker simulation
5. Verify blob detection, zone-presence events, portal-crossing
events, timeline entries, and MQTT/HA integration status
Added helper methods to TestHarness:
- CreateZone, CreatePortal, GetPortalCrossings
- GetTimeline, GetMQTTStatus
Closes: bf-1rifr
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Implement acceptance tests for single-node and multi-node fleet onboarding:
- IO-3 (TestIO3_SingleNodeOnboarding): Validates end-to-end onboarding of a
single simulated ESP32 node via spaxel-sim. Verifies node transitions from
discovered to online, appears in /api/nodes within 10s, and that label/position
assignments persist via REST API (PUT /api/nodes/{mac}/position and PATCH
/api/nodes/{mac}/label).
- IO-4 (TestIO4_MultiNodeFleetBringup): Validates multi-node fleet bring-up with
6 nodes. Verifies all nodes reach online status, no TX-slot collision warnings
in logs, /api/nodes shows all 6 online, and fleet telemetry data is available
via /api/fleet endpoint.
Also fixes a context leak in TestIO5_DeviceIdentityBLEOnboarding by ensuring
the simulator context cancel function is called with defer.
Closes: bf-4jcjg
Implements IO-5 acceptance test which verifies:
- A person can be created via POST /api/people
- A simulated BLE device (from spaxel-sim) is discovered
- The BLE device can be assigned to a person via PUT /api/ble/devices/{mac}
- The device registration is persisted correctly with person_id, person_name, and person_color
Also fixes a bug in mothership/cmd/mothership/main.go where
SetBriefingProvider was called before dashboardHub was initialized,
causing a nil pointer dereference on startup. The call is now
made after the hub is created.
Closes: bf-3cagn (IO-5: BLE device-identity onboarding test)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Adds three test cases for quality gate #7:
1. TestAS7_AuthRejectMissingToken - verifies nodes without tokens are rejected
2. TestAS7_AuthRejectInvalidToken - verifies nodes with invalid tokens are rejected
3. TestAS7_AuthAcceptValidToken - verifies nodes with valid tokens are accepted
Each test verifies:
- Simulator exits non-zero on rejection
- Mothership logs the rejection
- No nodes connect when auth fails
Closes: bf-2d9fj
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Implemented all 6 acceptance scenarios as verifiable integration tests:
- AS-1: First-time setup in under 5 minutes
- AS-2: Person detected while walking
- AS-3: Fall alert fires correctly
- AS-4: BLE identity resolves to person name
- AS-5: OTA update succeeds / rollback on bad firmware
- AS-6: Replay shows recorded history
Each scenario includes multiple test cases covering pass/fail criteria.
Tests use spaxel-sim as the test harness for simulating CSI data without
hardware. The integration test entry point runs all scenarios sequentially
for CI/CD verification.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Added comprehensive integration tests in test/acceptance/ covering all 6 acceptance scenarios from plan.md
- AS-1: First-time setup in under 5 minutes - verifies PIN setup and node auto-discovery
- AS-2: Person detected while walking - verifies blob detection during walker simulation
- AS-3: Fall alert fires correctly - verifies fall detection with webhook integration
- AS-4: BLE identity resolves to person name - verifies BLE device registration and identity matching
- AS-5: OTA update succeeds / rollback on bad firmware - verifies OTA workflow and rollback
- AS-6: Replay shows recorded history - verifies replay session creation, seeking, and playback
Tests use spaxel-sim CLI as the test harness and verify:
- API endpoint responses (/api/auth/setup, /api/nodes, /api/blobs, /api/events, /api/ble/devices, /api/replay/*)
- Detection accuracy thresholds (>60% blob presence during walking)
- Alert generation and webhook delivery
- Firmware version updates and rollback behavior
- Replay session lifecycle management
All tests skip by default unless ACCEPTANCE_TEST=1 or SPAXEL_INTEGRATION_TEST=1 is set.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
