59 lines
4.0 KiB
Markdown
59 lines
4.0 KiB
Markdown
|
---
|
|||
|
|
source_files:
|
|||
|
|
- Common/DTS.Common/Enums/TestSetups/TestSetupsList/TestSetupFields.cs
|
|||
|
|
generated_at: "2026-04-16T03:22:07.305062+00:00"
|
|||
|
|
model: "Qwen/Qwen3-Coder-Next-FP8"
|
|||
|
|
schema_version: 1
|
|||
|
|
sha256: "d9c52bce6858a67a"
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# TestSetupsList
|
|||
|
|
|
|||
|
|
### 1. **Purpose**
|
|||
|
|
This module defines a strongly-typed enumeration `TestSetupFields` used to represent the set of canonical field names associated with a test setup record in the DTS (presumably *Device Test System*) platform. It serves as a centralized, compile-time-safe reference for field identifiers—enabling consistent referencing across data access, UI binding, serialization, and validation layers—without relying on magic strings or hardcoded field names.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 2. **Public Interface**
|
|||
|
|
The module exports a single public type:
|
|||
|
|
|
|||
|
|
- **`TestSetupFields`** (`enum`)
|
|||
|
|
A fixed set of named constants representing metadata fields of a test setup. Each member corresponds to a logical column or property in a test setup entity:
|
|||
|
|
- `Name`: Identifier for the test setup.
|
|||
|
|
- `Description`: Human-readable description of the test setup.
|
|||
|
|
- `RecordingMode`: Specifies how data is recorded (e.g., continuous, triggered).
|
|||
|
|
- `PreTriggerSeconds`: Duration (in seconds) of data captured *before* a trigger event.
|
|||
|
|
- `PostTriggerSeconds`: Duration (in seconds) of data captured *after* a trigger event.
|
|||
|
|
- `LastModified`: Timestamp of the last modification.
|
|||
|
|
- `LastModifiedBy`: Identity (e.g., user ID or name) of the modifier.
|
|||
|
|
- `IsComplete`: Boolean flag indicating whether the test setup is finalized and ready for use.
|
|||
|
|
|
|||
|
|
No methods, properties, or constructors are defined on the enum.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 3. **Invariants**
|
|||
|
|
- The set of enum values is **immutable**—no fields may be added, removed, or renamed without updating all consumers.
|
|||
|
|
- Each value maps to a *semantic field* of a test setup; the enum itself does not enforce data types or nullability (e.g., `PreTriggerSeconds` is expected to be numeric, `IsComplete` boolean), but consumers must interpret values according to their documented semantics.
|
|||
|
|
- The enum values are **case-sensitive** and must match exactly (e.g., `"Name"` ≠ `"name"`) when used in string-based contexts (e.g., JSON property names, database column names).
|
|||
|
|
- The ordering of enum values is *not* semantically significant—iteration order should not be relied upon for correctness.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 4. **Dependencies**
|
|||
|
|
- **Depends on**: None (no external assemblies or types are referenced in the source).
|
|||
|
|
- **Used by**: Implicitly, any module that handles test setup metadata (e.g., data mappers, UI view models, API request/response models, database schemas). While not visible in this file, typical consumers would include:
|
|||
|
|
- Data access layers (e.g., ORM mappings, query builders)
|
|||
|
|
- REST API controllers (e.g., for filtering, sorting, or field selection)
|
|||
|
|
- Frontend components (e.g., form fields, column headers)
|
|||
|
|
- Serialization/deserialization logic (e.g., JSON converters)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 5. **Gotchas**
|
|||
|
|
- **No validation or default values**: The enum itself does not enforce constraints (e.g., `PreTriggerSeconds` ≥ 0, `IsComplete` only valid when `IsComplete == true`). Validation must be handled separately.
|
|||
|
|
- **String interoperability risk**: When used in JSON or database contexts, the enum’s underlying string representation (`"Name"`, `"RecordingMode"`, etc.) must be explicitly serialized (e.g., via `[JsonProperty("Name")]` or custom converters); otherwise, numeric values (0, 1, …) may be used, breaking compatibility.
|
|||
|
|
- **No extensibility**: Adding a new field requires recompiling *all* consumers—no backward-compatible extension mechanism is provided.
|
|||
|
|
- **Ambiguity in semantics**: The meaning of `RecordingMode` and `IsComplete` is not self-evident from the enum alone (e.g., what values does `RecordingMode` accept? What state does `IsComplete` reflect?). These require cross-referencing with related types (e.g., `RecordingMode` enum, test setup domain logic).
|
|||
|
|
|
|||
|
|
*None identified beyond the above.*
|