You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: monitoring/uss_qualifier/action_generators/README.md
+23Lines changed: 23 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,3 +3,26 @@
3
3
The bulk of uss_qualifier's automated testing logic is contained in [test scenarios](../scenarios/README.md). A [test suite](../suites/README.md) is essentially a static "playlist" of test actions to perform (test scenarios, action generators, and other test suites), all of which ultimately resolve to test scenarios. An action generator is essentially a dynamic "playlist" of test actions -- it can generate test actions that vary according to provided resource values, situations, or other conditions only necessarily known at runtime.
4
4
5
5
For documentation purposes, all action generators must statically declare the test actions they may take. However, whether each (or any) of these actions will actually be taken at runtime cannot be statically determined in general.
6
+
7
+
## Parallel execution in action generators
8
+
9
+
An action generator's `actions()` method yields one of:
10
+
11
+
- a `TestSuiteAction` — executed sequentially, as before.
12
+
- a `list[list[TestSuiteAction]]` — a *parallel group*. The outer list holds the branches to execute concurrently; each inner list is a sequence of actions executed in order within its own branch.
yield [[A1, A2, A3], [B1, B2, B3]] # A and B in parallel
20
+
```
21
+
22
+
When a parallel group is yielded, each branch runs on its own thread. Reports are appended to the parent report in branch order.
23
+
24
+
### Constraints
25
+
26
+
Each branch shares the same `Resource` instances unless the action generator hands out distinct ones. If a resource has mutable state that two branches would race on, the generator must produce isolated copies - typically by declaring `ResourceModifier`-based variants and calling `.adjust(index)` for each branch.
27
+
28
+
If a branch fails with `on_failure: Abort` (or hits a critical problem), the other branches are signalled to stop at the next action boundary. In-progress actions still finish.
Copy file name to clipboardExpand all lines: monitoring/uss_qualifier/action_generators/flight_planning/README.md
+10Lines changed: 10 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,3 +19,13 @@ This action generator accepts a [FlightPlannersResource](../../resources/flight_
19
19
|`ussC`|`ussC`|`ExampleTestScenario`|
20
20
21
21
The usage intent for this action generator is to enable design of simple test scenarios with a small number of participants, but to automatically repeat that simple scenario with all applicable role assignment combinations given a list of flight planner USSs to test.
22
+
23
+
## `ParallelFlightPlannerCombinations`
24
+
25
+
Variant of `FlightPlannerCombinations` that runs combinations in parallel where possible.
26
+
27
+
Same configuration as `FlightPlannerCombinations`. The only difference is scheduling: combinations sharing no flight planner participant are grouped together and executed concurrently. Combinations sharing at least one participant remain in different groups (so no participant is hit by two tests at the same time).
28
+
29
+
Groups are built greedily (first-fit): each combination is placed in the first existing group with no participant overlap, otherwise a new group is started. This is not minimal in the worst case but the problem is graph coloring, NP-hard.
30
+
31
+
Each combination receives its own `adjust(index)` variant of every `ResourceModifier` resource in the pool (inherited from `FlightPlannerCombinations`), so parallel branches don't share mutable resource state.
0 commit comments