brent.edwards
b67dc63eda
CI / lint (pull_request) Successful in 1m2s
CI / quality (pull_request) Successful in 39s
CI / typecheck (pull_request) Successful in 2m21s
CI / benchmark-publish (pull_request) Has been skipped
CI / security (pull_request) Successful in 2m36s
CI / build (pull_request) Successful in 21s
CI / e2e_tests (pull_request) Successful in 2m6s
CI / integration_tests (pull_request) Successful in 3m57s
CI / unit_tests (pull_request) Successful in 4m5s
CI / docker (pull_request) Successful in 58s
CI / coverage (pull_request) Successful in 6m37s
CI / benchmark-regression (pull_request) Successful in 37m33s
Write Behave scenario and Robot Framework test proving that SubplanService.spawn() only creates metadata (SubplanStatus records and SpawnMetadata) without creating real child Plan domain objects or triggering lifecycle progression. Tests are tagged @tdd_expected_fail so CI passes via result inversion. ISSUES CLOSED: #838
35 lines
1.8 KiB
Gherkin
35 lines
1.8 KiB
Gherkin
@tdd_expected_fail @tdd_bug @tdd_bug_823 @mock_only
|
|
Feature: TDD Bug #823 — subplan spawn creates metadata but does not orchestrate child plan execution
|
|
As a developer
|
|
I want to verify that SubplanService.spawn() creates real child Plan
|
|
domain objects and triggers their lifecycle progression
|
|
So that the bug is captured and will be caught by a regression test
|
|
|
|
SubplanService.spawn() currently creates SubplanStatus records and
|
|
SpawnMetadata but does NOT create actual child Plan domain objects,
|
|
trigger the strategize phase on child plans, set up inter-plan
|
|
communication, merge results, or handle child plan failures. These
|
|
tests assert the expected behaviour and will FAIL until the bug is
|
|
fixed. The @tdd_expected_fail tag inverts the result so CI passes.
|
|
|
|
Scenario: Spawn result contains child Plan domain objects
|
|
Given a parent plan configured for subplan spawning
|
|
And valid spawn entries for the parent plan
|
|
When I spawn subplans via SubplanService
|
|
Then the spawn result should contain child Plan domain objects
|
|
And each child Plan should have parent_plan_id set to the parent
|
|
|
|
Scenario: Child plans enter the strategize phase after spawn
|
|
Given a parent plan configured for subplan spawning
|
|
And valid spawn entries for the parent plan
|
|
When I spawn subplans via SubplanService
|
|
Then each child plan should be in the strategize phase
|
|
And each child plan processing state should be queued
|
|
|
|
Scenario: Parent plan tracks child plan lifecycle status
|
|
Given a parent plan configured for subplan spawning
|
|
And valid spawn entries for the parent plan
|
|
When I spawn subplans via SubplanService
|
|
Then the parent plan subplan_statuses should reflect child lifecycle
|
|
And the spawn result total_spawned should match child plan count
|