--- source_files: - Common/DTS.Common/Events/TestSetups/TestSetupsList/CurrentTestIdChangedEvent.cs - Common/DTS.Common/Events/TestSetups/TestSetupsList/CurrentTestChangedEvent.cs - Common/DTS.Common/Events/TestSetups/TestSetupsList/TestSetupsListEditTestSetupEvent.cs - Common/DTS.Common/Events/TestSetups/TestSetupsList/TestSetupsListTestSetupSelectedEvent.cs generated_at: "2026-04-16T03:27:18.056477+00:00" model: "Qwen/Qwen3-Coder-Next-FP8" schema_version: 1 sha256: "147ad5f06ebe2c02" --- # TestSetupsList ## Documentation: TestSetupsList Events Module ### 1. Purpose This module defines a set of Prism-based pub/sub events used to coordinate state changes and user interactions within the *Test Setups List* UI component. Specifically, it enables decoupled communication between view models or services involved in managing test setups—such as tracking the currently selected test, signaling edits, or handling selection changes—by publishing strongly-typed events through the `Prism.Events.EventAggregator`. These events facilitate reactive UI updates and state synchronization without tight coupling. --- ### 2. Public Interface All classes are `public` and inherit from `Prism.Events.PubSubEvent`, making them suitable for subscription and publication via `IEventAggregator`. | Event Class | Payload Type | Signature & Behavior | |-------------|--------------|----------------------| | `CurrentTestIdChangedEvent` | `string` | `public class CurrentTestIdChangedEvent : PubSubEvent`
• Published when the *ID* of the current test changes (e.g., user navigates to a different test).
• Payload is the **new test ID** (a `string`). | | `CurrentTestChangedEvent` | `string` | `public class CurrentTestChangedEvent : PubSubEvent`
• Published when the *entire current test setup* changes (not just its ID).
• Payload is the **new test ID** (a `string`).
• *Note:* Despite the semantic difference implied by the names, both events carry the same payload type and likely the same value (the test ID). | | `TestSetupsListEditTestSetupEvent` | `string` | `public class TestSetupsListEditTestSetupEvent : PubSubEvent`
• Published when the user initiates editing of a test setup.
• Payload is the **ID of the test setup to be edited** (a `string`). | | `TestSetupsListTestSetupSelectedEvent` | `string[]` | `public class TestSetupsListTestSetupSelectedEvent : PubSubEvent`
• Published when one or more test setups are selected (e.g., via checkbox or multi-select UI).
• Payload is an array of **test setup IDs** (a `string[]`).
• *Note:* XML comment incorrectly refers to this as `TTSImportSummaryImportEvent`—this is likely a copy-paste error. | --- ### 3. Invariants - **Payload semantics**: - For `CurrentTestIdChangedEvent`, `CurrentTestChangedEvent`, and `TestSetupsListEditTestSetupEvent`, the payload is a single test ID (`string`). - For `TestSetupsListTestSetupSelectedEvent`, the payload is an array of test IDs (`string[]`). - **Event naming consistency**: All events reside in the `DTS.Common.Events.TestSetups.TestSetupsList` namespace and follow the `*Event` suffix convention. - **No validation**: Events carry raw IDs; no validation (e.g., null-check, format validation) is performed *within the event class itself*. Consumers are responsible for handling invalid payloads. - **Ordering**: No ordering guarantees are implied—events may be published/subscribed asynchronously via Prism’s `PubSubEvent`. --- ### 4. Dependencies - **Dependencies *of* this module**: - `Prism.Events` (via `using Prism.Events;`) — required for `PubSubEvent`. - .NET runtime (standard for Prism-based projects). - **Dependencies *on* this module**: - Any module/view model interacting with the *Test Setups List* UI (e.g., a test list view model, a test editor, or a test selection handler) will likely subscribe to these events. - Specifically, components handling test selection, navigation, or editing workflows depend on these events for state propagation. - **Inferred consumers** (not visible in source, but typical for Prism patterns): - View models bound to the test setups list UI. - Navigation or routing services that respond to `CurrentTestChangedEvent`. - Editor launchers that handle `TestSetupsListEditTestSetupEvent`. - Multi-select action handlers (e.g., bulk operations) that react to `TestSetupsListTestSetupSelectedEvent`. --- ### 5. Gotchas - **Ambiguous semantics between `CurrentTestIdChangedEvent` and `CurrentTestChangedEvent`**: Both events carry `string` payloads (test IDs) and have nearly identical documentation. It is unclear whether: - `CurrentTestIdChangedEvent` is intended for *ID-only* changes (e.g., renaming a test without reloading its full setup), - or if one is legacy/unused. **Recommendation**: Clarify with domain experts or inspect subscribers to confirm intended usage. - **Misleading XML comment for `TestSetupsListTestSetupSelectedEvent`**: The `` and `` incorrectly reference `TTSImportSummaryImportEvent` and "Import button was clicked", which contradicts the class name and payload (`string[]` vs. likely a single import action). This is likely a copy-paste artifact and may mislead developers. - **No null-safety guarantees**: Payloads may be `null` (e.g., if a test is deselected or cleared). Subscribers must handle `null` or empty strings/arrays. - **No event grouping or cancellation**: Events are fire-and-forget; no mechanism is provided for throttling, debouncing, or canceling propagation. - **No versioning or schema evolution**: Payloads are unstructured (`string`/`string[]`). If test ID format changes (e.g., GUID → composite key), all subscribers must be updated manually. None identified beyond the above.