mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-06-23 04:41:13 +00:00
Oleksandr Bezdieniezhnykh
1f634c2604
ci/woodpecker/push/02-build-push Pipeline failed
- Modified the autodev state to reflect the current testing phase and details of the new `jetson-e2e` tests. - Enhanced the "How to Test" documentation to provide clearer instructions on the demo replay validation process, including video and tlog alignment steps. - Updated architectural documentation to include the new demo replay operator flow and its dependencies. - Documented the removal of deprecated auto-sync features and clarified the operator-facing UI for replay validation. - Added new entries in the dependencies table for upcoming tasks related to the demo replay flow. These changes improve clarity and usability for operators and developers working with the demo replay system.
3.1 KiB
3.1 KiB
Step 3: Blackbox Test Task Decomposition (tests-only mode only)
Role: Professional Quality Assurance Engineer Goal: Decompose blackbox test specs into atomic, implementable task specs. Constraints: Behavioral specs only — describe what, not how. No test code.
Numbering
- In tests-only mode: start from 02 (01 is the test infrastructure bootstrap from Step 1t).
Steps
- Read all test specs from
DOCUMENT_DIR/tests/(blackbox-tests.md,performance-tests.md,resilience-tests.md,security-tests.md,resource-limit-tests.md) - Group related test scenarios into atomic tasks (e.g., one task per test category or per component under test)
- Each task should reference the specific test scenarios it implements and the environment/test-data specs
- Add a System Under Test Boundary section to every e2e/blackbox test task:
- The test must drive the product through public runtime boundaries and compare actual outputs to
_docs/00_problem/input_data/expected_results/results_report.mdand any referenced machine-readable expected-result files. - Stubs are allowed only for external systems outside the product boundary: flight controller/SITL, QGC observer, satellite-provider/Suite service, physical Jetson hardware, physical camera, licensed public datasets, and network services.
- Stubs, fakes, deterministic fallbacks, monkeypatches, or direct imports are not allowed for internal product modules that the scenario is meant to validate, such as VIO, safety/anchor wrapper, satellite retrieval, anchor verification, tile manager, MAVLink output adapter, or FDR.
- If an internal module is not implemented, the test must fail/block as missing product implementation; it must not pass by replacing that module with a test stub.
- The test must drive the product through public runtime boundaries and compare actual outputs to
- Dependencies:
- In tests-only mode: blackbox test tasks depend on the test infrastructure bootstrap task (Step 1t)
- Write each task spec using
templates/task.md - Estimate complexity per task (1, 2, 3, 5 points); no task should exceed 5 points — split if it does
- Note task dependencies (referencing tracker IDs of already-created dependency tasks)
- Immediately after writing each task file: create a work item ticket under the "Blackbox Tests" epic, write the work item ticket ID and Epic ID back into the task header, then rename the file from
todo/[##]_[short_name].mdtotodo/[TRACKER-ID]_[short_name].md.
Self-verification
- Every scenario from
tests/blackbox-tests.mdis covered by a task - Every scenario from
tests/performance-tests.md,tests/resilience-tests.md,tests/security-tests.md, andtests/resource-limit-tests.mdis covered by a task - No task exceeds 5 complexity points
- Dependencies correctly reference the test infrastructure task
- Every task has a work item ticket linked to the "Blackbox Tests" epic
- Every e2e/blackbox task forbids internal product stubs/fakes and requires comparison against expected-results artifacts
Save action
Write each todo/[##]_[short_name].md (temporary numeric name), create work item ticket inline, then rename to todo/[TRACKER-ID]_[short_name].md.