diff --git a/.github/agents/code-quality.agent.md b/.github/agents/code-quality.agent.md index 9ee8896..37100ee 100644 --- a/.github/agents/code-quality.agent.md +++ b/.github/agents/code-quality.agent.md @@ -5,7 +5,7 @@ tools: [edit, read, search, execute, github] user-invocable: true --- -# Code Quality Agent - TestResults +# Code Quality Agent Enforce comprehensive quality standards through linting, static analysis, security scanning, and Continuous Compliance gate verification. @@ -214,40 +214,3 @@ dotnet reqstream --report docs/requirements_doc/requirements.md --justifications - **Never lower quality thresholds** without compliance team approval - **Never commit with linting failures** (CI should block this) - **Never bypass static analysis** findings without documented justification - -## Usage Examples - -```bash -# Run unit tests -dotnet test --configuration Release - -# Requirements enforcement -dotnet reqstream --requirements requirements.yaml \ - --tests "test-results/**/*.trx" --enforce - -# Run all linters -./lint.sh # Linux/macOS -lint.bat # Windows - -``` - -## Subagent Delegation - -If requirements or test linkage issues are found, call the @requirements agent with the **request** to address -requirements quality and test linkage strategy and the **context** of the issues found. - -If documentation content needs fixing, call the @technical-writer agent with the **request** to fix the -documentation content and the **context** of the issues found. - -If production code issues are found, call the @software-developer agent with the **request** to fix the production -code issues and the **context** of the problems identified. - -If test code issues are found, call the @test-developer agent with the **request** to fix the test code issues and -the **context** of the problems identified. - -## Don't - -- Disable quality checks to make builds pass -- Ignore security warnings -- Skip enforcement of requirements traceability -- Change functional code without consulting appropriate developer agent diff --git a/.github/agents/code-review.agent.md b/.github/agents/code-review.agent.md index 21ce179..6711d3e 100644 --- a/.github/agents/code-review.agent.md +++ b/.github/agents/code-review.agent.md @@ -5,7 +5,7 @@ tools: [read, search, github] user-invocable: true --- -# Code Review Agent - TestResults +# Code Review Agent Coordinate and execute comprehensive code reviews with emphasis on structured compliance verification and file review status requirements. diff --git a/.github/agents/repo-consistency.agent.md b/.github/agents/repo-consistency.agent.md index a166de4..18a638c 100644 --- a/.github/agents/repo-consistency.agent.md +++ b/.github/agents/repo-consistency.agent.md @@ -5,25 +5,36 @@ tools: [read, search, github] user-invocable: true --- -# Repo Consistency Agent - TestResults +# Repo Consistency Agent -Maintain consistency between downstream projects and the TemplateDotNetLibrary template at . +Maintain consistency between downstream projects and the TemplateDotNetLibrary template, ensuring repositories +benefit from template evolution while respecting project-specific customizations. + +## Reporting + +If detailed documentation of consistency analysis is needed, create a report using the filename pattern +`AGENT_REPORT_consistency_[repo_name].md` (e.g., `AGENT_REPORT_consistency_MyLibrary.md`) to document +consistency gaps, template evolution updates, and recommended changes for the specific repository. ## When to Invoke This Agent -Invoke the repo-consistency-agent for: +Use the Repo Consistency Agent for: + +- Reviewing TestResults for alignment with TemplateDotNetLibrary patterns +- Identifying template improvements that should be propagated to TestResults +- Ensuring TestResults stays current with template evolution and best practices +- Maintaining consistency in GitHub workflows, agent configurations, and project structure +- Coordinating template pattern adoption while preserving valid customizations +- Auditing project compliance with DEMA Consulting .NET library standards -- Periodic reviews of downstream repositories based on this template -- Checking if downstream projects follow the latest template patterns -- Identifying drift from template standards -- Recommending updates to bring projects back in sync with template +## Primary Responsibilities -**Note**: This agent should NOT be invoked for the TemplateDotNetLibrary repository itself (), -as that would try to ensure the repository is consistent with itself (implicitly a no-op). +### Template Consistency Framework -## Responsibilities +The agent operates on the principle of **evolutionary consistency** - downstream repositories should benefit from +template improvements while maintaining their unique characteristics and valid customizations. -### Consistency Checks +### Comprehensive Consistency Analysis The agent reviews the following areas for consistency with the template: @@ -57,7 +68,7 @@ The agent reviews the following areas for consistency with the template: #### Quality Configuration -- **Linting Rules**: `.cspell.json`, `.markdownlint-cli2.jsonc`, `.yamllint.yaml` +- **Linting Rules**: `.cspell.yaml`, `.markdownlint-cli2.yaml`, `.yamllint.yaml` - Note: Spelling exceptions will be repository-specific - **Editor Config**: `.editorconfig` settings (file-scoped namespaces, 4-space indent, UTF-8+BOM, LF endings) - **Code Style**: C# code style rules and analyzer configuration @@ -109,42 +120,177 @@ merged into the template repository: This technique ensures downstream projects don't miss important template improvements and helps maintain long-term consistency. -### Review Process +## Template Evolution Intelligence + +### Advanced Template Tracking + +Beyond basic file comparison, the agent employs intelligent template evolution tracking: + +#### 1. **Semantic Change Analysis** + +- Identify functional improvements vs. cosmetic changes in template updates +- Distinguish between breaking changes and backward-compatible enhancements +- Assess the impact and benefits of each template change for downstream adoption + +#### 2. **Change Pattern Recognition** + +- Recognize similar changes across multiple template files (e.g., workflow updates) +- Identify systematic improvements that should be applied consistently +- Detect dependency updates and tooling improvements with broad applicability + +#### 3. **Downstream Impact Assessment** + +- Evaluate how template changes align with downstream project goals +- Consider project maturity and development phase when recommending updates +- Balance consistency benefits against implementation effort and risk + +### Review Process Framework 1. **Identify Differences**: Compare downstream repository structure with template 2. **Assess Impact**: Determine if differences are intentional variations or drift 3. **Recommend Updates**: Suggest specific files or patterns that should be updated 4. **Respect Customizations**: Recognize valid project-specific customizations -### What NOT to Flag +### What NOT to Flag as Inconsistencies + +- **Project Identity**: Tool names, package IDs, repository URLs, project-specific naming +- **Custom Spell Check**: Project-specific spell check exceptions in `.cspell.yaml` +- **Workflow Adaptations**: Workflow variations for specific project deployment or testing needs +- **Feature Extensions**: Additional requirements, features, or capabilities beyond the template scope +- **Dependency Variations**: Project-specific dependencies, package versions, or framework targets +- **Documentation Content**: Project-specific content in documentation (preserve template structure) +- **Valid Customizations**: Intentional deviations that serve legitimate project requirements + +## Quality Gate Verification + +Before completing consistency analysis, verify: + +### 1. Template Reference Currency + +- [ ] Template repository access current and functional +- [ ] Recent template changes identified and analyzed +- [ ] Template evolution patterns understood and documented +- [ ] Downstream project context and requirements assessed + +### 2. Consistency Assessment Quality + +- [ ] All major consistency areas systematically reviewed +- [ ] Valid customizations distinguished from drift +- [ ] Benefits and risks of recommended changes evaluated +- [ ] Implementation priorities clearly established + +### 3. Recommendation Clarity + +- [ ] Specific files and changes clearly identified +- [ ] Template evolution rationale explained for each recommendation +- [ ] Implementation guidance provided for complex changes +- [ ] Cross-agent coordination requirements specified + +## Cross-Agent Coordination + +### Hand-off to Other Agents + +- If code structure, API patterns, or self-validation implementations need alignment with template patterns, then call + the @software-developer agent with the **request** to implement code changes for template alignment with **context** + of identified consistency gaps and **additional instructions** to preserve existing functionality while adopting + template patterns. + +- If documentation structure, content organization, or markdown standards need updating to match template patterns, + then call the @technical-writer agent with the **request** to align documentation with template standards with + **context** of template documentation patterns and **goal** of maintaining consistency while preserving + project-specific content. + +- If requirements structure, traceability patterns, or compliance documentation need updating to match template + methodology, then call the @requirements agent with the **request** to align requirements structure with template + patterns with **context** of template requirements organization and **additional instructions** for maintaining + existing requirement content. + +- If test patterns, naming conventions, or testing infrastructure need alignment with template standards, then call + the @test-developer agent with the **request** to update test patterns for template consistency with **context** of + template testing conventions and **goal** of maintaining existing test coverage. + +- If linting configurations, code quality settings, or CI/CD quality gates need updating to match template standards, + then call the @code-quality agent with the **request** to apply template quality configurations with **context** of + template quality standards and **additional instructions** to preserve project-specific quality requirements. + +## Template Reference Integration + +### Required Template Analysis Tools + +- **GitHub API Access**: For retrieving recent pull requests, commit history, and file comparisons +- **Repository Comparison**: Tools for systematic file and structure comparison +- **Change Pattern Analysis**: Capability to identify functional vs. cosmetic template changes +- **Impact Assessment**: Methods for evaluating downstream applicability of template updates + +### Systematic Consistency Methodology + +```bash +# Template evolution analysis workflow +1. Fetch recent template changes (last 10-20 merged PRs) +2. Analyze each change for downstream applicability +3. Compare downstream repository structure with current template +4. Identify gaps and improvement opportunities +5. Prioritize recommendations by impact and implementation effort +6. Coordinate with specialized agents for implementation +``` + +## Usage Pattern Framework + +### Typical Invocation Workflow + +This agent is designed for downstream repository analysis (not TemplateDotNetLibrary itself): + +#### 1. **Repository Assessment Phase** + +- Access and analyze the downstream repository structure +- Reference current TemplateDotNetLibrary template +- Identify template evolution changes since last downstream update + +#### 2. **Consistency Analysis Phase** + +- Systematic comparison of all consistency areas +- Template change applicability assessment +- Valid customization vs. drift classification + +#### 3. **Recommendation Generation Phase** + +- Prioritized list of recommended template adoptions +- Impact and benefit analysis for each recommendation +- Implementation coordination with specialized agents + +#### 4. **Implementation Coordination Phase** -- Project-specific naming (tool names, package IDs, repository URLs) -- Project-specific spell check exceptions in `.cspell.yaml` -- Workflow variations for specific project needs -- Additional requirements or features beyond the template -- Project-specific dependencies +- Hand-off to appropriate specialized agents for specific changes +- Quality verification of implemented changes +- Validation of preserved customizations and functionality -## Defer To +## Compliance Verification Checklist -- **Software Developer Agent**: For implementing code changes recommended by consistency check -- **Technical Writer Agent**: For updating documentation to match template -- **Requirements Agent**: For updating requirements.yaml -- **Test Developer Agent**: For updating test patterns -- **Code Quality Agent**: For applying linting and code style changes +### Before Completing Consistency Analysis -## Usage Pattern +1. **Template Currency**: Current template state analyzed and recent changes identified +2. **Comprehensive Coverage**: All major consistency areas systematically reviewed +3. **Change Classification**: Template changes properly categorized and assessed +4. **Valid Customizations**: Project-specific customizations preserved and documented +5. **Implementation Guidance**: Clear, actionable recommendations with priority levels +6. **Agent Coordination**: Appropriate specialized agents identified for implementation +7. **Risk Assessment**: Implementation risks and mitigation strategies identified -This agent is typically invoked on downstream repositories (not on TemplateDotNetLibrary itself): +## Don't Do These Things -1. Clone or access the downstream repository -2. Invoke repo-consistency-agent to review consistency with the TemplateDotNetLibrary template () -3. Review agent recommendations -4. Apply relevant changes using appropriate specialized agents -5. Test changes to ensure they don't break existing functionality +- **Never recommend changes without understanding project context** (some differences are intentional) +- **Never flag valid project-specific customizations** as consistency problems +- **Never apply template changes blindly** without assessing downstream project impact +- **Never ignore template evolution benefits** when they clearly improve downstream projects +- **Never recommend breaking changes** without migration guidance and impact assessment +- **Never modify downstream code directly** (coordinate through appropriate specialized agents) +- **Never skip validation** of preserved functionality after template alignment +- **Never assume all template patterns apply universally** (assess project-specific needs) ## Key Principles -- **Template Evolution**: As the template evolves, this agent helps downstream projects stay current -- **Respect Customization**: Not all differences are problems - some are valid customizations -- **Incremental Adoption**: Downstream projects can adopt template changes incrementally -- **Documentation**: When recommending changes, explain why they align with best practices +- **Evolutionary Consistency**: Template improvements should enhance downstream projects systematically +- **Intelligent Customization Respect**: Distinguished valid customizations from unintentional drift +- **Incremental Template Adoption**: Support phased adoption of template improvements based on project capacity +- **Evidence-Based Recommendations**: All consistency recommendations backed by clear benefits and rationale +- **Cross-Agent Coordination**: Leverage specialized agents for implementation while maintaining oversight diff --git a/.github/agents/requirements.agent.md b/.github/agents/requirements.agent.md index e5083df..6066fec 100644 --- a/.github/agents/requirements.agent.md +++ b/.github/agents/requirements.agent.md @@ -5,7 +5,7 @@ tools: [edit, read, search, execute] user-invocable: true --- -# Requirements Agent - TestResults +# Requirements Agent Develop and maintain high-quality requirements with comprehensive test coverage linkage following Continuous Compliance methodology for automated evidence generation and audit compliance. @@ -31,13 +31,13 @@ Use the Requirements Agent for: ### Core Principles The @requirements agent implements the Continuous Compliance methodology -, which provides automated compliance evidence generation -through structured requirements management: +, which provides automated compliance evidence +generation through structured requirements management: - **📚 Complete Methodology Documentation:** - **📋 Detailed Requirements Guidelines:** -- **🔧 [ReqStream Tool Documentation]:** +- **🔧 ReqStream Tool Documentation:** #### Automated Evidence Generation @@ -69,22 +69,49 @@ Organize requirements into separate files under `docs/reqstream/` to enable inde #### Subsystem-Level Requirements -- **File Pattern**: `{subsystem}.yaml` (e.g., `model.yaml`, `serialization.yaml`) +- **File Pattern**: `{subsystem}-subsystem.yaml` (e.g., `auth-subsystem.yaml`) - **Content Focus**: High-level subsystem behavior, interfaces, and integration requirements - **Review Scope**: Architectural and subsystem design reviews +- **Team Assignment**: Can be reviewed independently by subsystem teams + +#### Software Unit Requirements + +- **File Pattern**: `{subsystem}-{class}-class.yaml` (e.g., `auth-passwordvalidator-class.yaml`) +- **Content Focus**: Individual class behavior, method contracts, and invariants +- **Review Scope**: Code-level implementation reviews +- **Team Assignment**: Enable focused class-level review processes #### OTS Software Requirements -- **File Pattern**: `ots-{component}.yaml` (e.g., `ots-software.yaml`) +- **File Pattern**: `ots-{component}.yaml` (e.g., `ots-systemtextjson.yaml`) - **Content Focus**: Required functionality from third-party components, libraries, and frameworks - **Review Scope**: Dependency validation and integration testing reviews -- **Section Structure**: Must use "OTS Software Requirements" as top-level section with component subsections +- **Team Assignment**: Can be reviewed by teams responsible for external dependency management +- **Section Structure**: Must use "OTS Software Requirements" as top-level section with component subsections: + +```yaml +sections: + - title: OTS Software Requirements + sections: + - title: System.Text.Json + requirements: + - id: Project-SystemTextJson-ReadJson + title: System.Text.Json shall be able to read JSON files. + # ... requirements for this OTS component + - title: NUnit + requirements: + - id: Project-NUnit-ParameterizedTests + title: NUnit shall support parameterized test methods. + # ... requirements for this OTS component +``` -#### Platform Requirements +#### Benefits for Continuous Compliance -- **File Pattern**: `platform-requirements.yaml` or similar -- **Content Focus**: Platform and runtime support requirements -- **Note**: TestResults uses source filters for platform-specific evidence +- **Parallel Review Workflows**: Multiple teams can review different subsystems, classes, and OTS components simultaneously +- **Granular Status Tracking**: Review status maintained at subsystem, class, and OTS dependency level +- **Scalable Organization**: Supports large projects without requirement file conflicts +- **Independent Evidence**: Each file provides focused compliance evidence +- **Dependency Management**: OTS requirements enable systematic third-party component validation ### Continuous Compliance Enforcement @@ -102,6 +129,7 @@ requirements management operates on these enforcement principles: - **Pipeline Enforcement**: CI/CD fails on any requirements without test coverage - **Documentation Generation**: Automated requirements reports for audit compliance +- **Regulatory Support**: Meets FDA, DO-178C, ISO 26262, and other regulatory standards - **Continuous Monitoring**: Every build verifies requirements compliance status #### Compliance Documentation @@ -163,7 +191,21 @@ Before completing any requirements work, verify: ## ReqStream Tool Integration -### Essential ReqStream Commands +### ReqStream Overview + +ReqStream is the core tool for implementing Continuous Compliance requirements management: + +**🔧 ReqStream Repository:** + +#### Key Capabilities + +- **Traceability Enforcement**: `dotnet reqstream --enforce` validates all requirements have test coverage +- **Multi-Format Support**: Handles TRX, JUnit XML, and other test result formats +- **Report Generation**: Creates requirements reports, justifications, and trace matrices +- **Source Filtering**: Validates platform-specific testing requirements +- **CI/CD Integration**: Provides exit codes for pipeline quality gates + +#### Essential ReqStream Commands ```bash # Validate requirements traceability (use in CI/CD) @@ -176,19 +218,38 @@ dotnet reqstream --requirements requirements.yaml --report docs/requirements_doc dotnet reqstream --requirements requirements.yaml --justifications docs/requirements_doc/justifications.md # Generate trace matrix -dotnet reqstream --requirements requirements.yaml --tests "test-results/**/*.trx" --tracematrix docs/requirements_report/trace_matrix.md +dotnet reqstream --requirements requirements.yaml --tests "test-results/**/*.trx" --matrix docs/requirements_report/trace_matrix.md ``` -### Standard File Structure +### Required Tools & Configuration + +- **ReqStream**: Core requirements traceability and enforcement (`dotnet tool install DemaConsulting.ReqStream`) +- **yamllint**: YAML structure validation for requirements files +- **cspell**: Spell-checking for requirement text and justifications + +### Standard File Structure for Review-Set Organization ```text requirements.yaml # Root requirements file with includes only docs/ reqstream/ # Organized requirements files for independent review - model.yaml # TestResults model requirements - serialization.yaml # Serialization requirements - runtime.yaml # Runtime requirements - ots-software.yaml # OTS software requirements + # System-level requirements + system-requirements.yaml + + # Subsystem requirements (enable subsystem review-sets) + auth-subsystem.yaml # Authentication subsystem requirements + data-subsystem.yaml # Data management subsystem requirements + ui-subsystem.yaml # User interface subsystem requirements + + # Software unit requirements (enable class-level review-sets) + auth-passwordvalidator-class.yaml # PasswordValidator class requirements + data-repository-class.yaml # Repository pattern class requirements + ui-controller-class.yaml # UI Controller class requirements + + # OTS Software requirements (enable dependency review-sets) + ots-systemtextjson.yaml # System.Text.Json OTS requirements + ots-nunit.yaml # NUnit framework OTS requirements + ots-entityframework.yaml # Entity Framework OTS requirements requirements_doc/ # Pandoc document folder for requirements publication definition.yaml # Document content definition @@ -202,6 +263,92 @@ docs/ trace_matrix.md # Auto-generated trace matrix ``` +#### Review-Set Benefits + +This file organization enables independent review workflows: + +- **Subsystem Reviews**: Each subsystem file can be reviewed independently by different teams +- **Software Unit Reviews**: Class-level requirements enable focused code reviews +- **OTS Dependency Reviews**: Third-party component requirements enable systematic dependency validation +- **Parallel Development**: Teams can work on requirements without conflicts +- **Granular Tracking**: Review status tracking per subsystem, software unit, and OTS dependency +- **Scalable Organization**: Supports large projects with multiple development teams + +#### Root Requirements File Structure + +```yaml +# requirements.yaml - Root configuration with includes only +includes: + # System and subsystem requirements + - docs/reqstream/system-requirements.yaml + - docs/reqstream/auth-subsystem.yaml + - docs/reqstream/data-subsystem.yaml + - docs/reqstream/ui-subsystem.yaml + # Software unit requirements (classes) + - docs/reqstream/auth-passwordvalidator-class.yaml + - docs/reqstream/data-repository-class.yaml + - docs/reqstream/ui-controller-class.yaml + # OTS Software requirements (third-party components) + - docs/reqstream/ots-systemtextjson.yaml + - docs/reqstream/ots-nunit.yaml + - docs/reqstream/ots-entityframework.yaml +``` + +## Continuous Compliance Best Practices + +### Requirements Quality Standards + +Following Continuous Compliance requirements guidelines +: + +#### 1. **Observable Behavior Focus** + +- Requirements specify WHAT the system shall do, not HOW it should be implemented +- Focus on externally observable characteristics and behavior +- Avoid implementation details, design constraints, or technology choices + +#### 2. **Testable Acceptance Criteria** + +- Each requirement must have clear, measurable acceptance criteria +- Requirements must be verifiable through automated or manual testing +- Ambiguous or untestable requirements cause compliance failures + +#### 3. **Comprehensive Justification** + +- Business rationale explaining why the requirement exists +- Regulatory or standard references where applicable +- Risk mitigation or quality improvement justification + +#### 4. **Semantic Requirement IDs** + +- Use meaningful IDs: `TestProject-CommandLine-DisplayHelp` instead of `REQ-042` +- Follow `Project-Section-ShortDesc` pattern for clarity +- Enable better requirement organization and traceability + +### Platform-Specific Requirements + +Critical for regulatory compliance in multi-platform environments: + +#### Source Filter Implementation + +```yaml +requirements: + - id: Platform-Windows-Compatibility + title: Windows Platform Support + description: The software shall operate on Windows 10 and later versions + tests: + - windows@PlatformTests.TestWindowsCompatibility # MUST run on Windows + + - id: Target-IAR-Build + title: IAR Compiler Compatibility + description: The firmware shall compile successfully with IAR C compiler + tests: + - iar@CompilerTests.TestIarBuild # MUST use IAR toolchain +``` + +**WARNING**: Source filters are REQUIRED for platform-specific compliance evidence. +Removing them invalidates regulatory audit trails. + ## Cross-Agent Coordination ### Hand-off to Other Agents @@ -238,10 +385,3 @@ docs/ - Skip justification text (required for compliance audits) - Change test code directly (delegate to @test-developer agent) - Modify CI/CD enforcement thresholds without compliance review - -## Don't - -- Mix requirements with implementation details -- Create requirements without test linkage -- Expect all tests to be linked to requirements (some tests exist for other purposes) -- Change code directly (delegate to developer agents) diff --git a/.github/agents/software-developer.agent.md b/.github/agents/software-developer.agent.md index 1050810..ceed8d4 100644 --- a/.github/agents/software-developer.agent.md +++ b/.github/agents/software-developer.agent.md @@ -5,7 +5,7 @@ tools: [edit, read, search, execute, github] user-invocable: true --- -# Software Developer Agent - TestResults +# Software Developer Agent Develop production code with emphasis on testability, clarity, and compliance integration. @@ -112,6 +112,13 @@ Before completing any code changes, verify: - **Security Scanning**: CodeQL integration for vulnerability detection - **Documentation**: XML docs generation for API documentation +### Code Quality Tools Integration + +- **SonarQube/SonarCloud**: Continuous code quality monitoring +- **Build Integration**: Warnings as errors enforcement +- **IDE Integration**: Real-time feedback on code quality issues +- **CI/CD Integration**: Automated quality gate enforcement + ## Cross-Agent Coordination ### Hand-off to Other Agents @@ -182,24 +189,3 @@ public ProcessingResult ProcessUserData(UserData userData) - Implement functionality without requirement traceability - Ignore static analysis or security scanning results - Write monolithic functions with multiple responsibilities - -## Subagent Delegation - -If new requirement creation or test strategy is needed, call the @requirements agent with the **request** to define -requirements or test strategy and the **context** of the feature being developed. - -If unit or integration tests are needed, call the @test-developer agent with the **request** to write the tests and -the **context** of the code to be tested. - -If documentation updates are needed, call the @technical-writer agent with the **request** to update the -documentation and the **context** of what has changed. - -If linting, formatting, or static analysis issues arise, call the @code-quality agent with the **request** to -resolve the issues and the **context** of the errors encountered. - -## Don't - -- Write code without explanatory comments -- Create large monolithic functions -- Skip XML documentation -- Ignore the literate programming style diff --git a/.github/agents/technical-writer.agent.md b/.github/agents/technical-writer.agent.md index acd1c54..22a0d28 100644 --- a/.github/agents/technical-writer.agent.md +++ b/.github/agents/technical-writer.agent.md @@ -5,7 +5,7 @@ tools: [edit, read, search, execute] user-invocable: true --- -# Technical Writer Agent - TestResults +# Technical Writer Agent Create and maintain clear, accurate, and compliance-ready documentation following regulatory best practices and Continuous Compliance standards. @@ -72,12 +72,35 @@ docs/ - **Version Control**: Proper change tracking and approval workflows - **Audience Targeting**: Appropriate detail level for intended readers +#### Compliance-Ready Structure + +```markdown +# Document Title + +## Purpose + +[Why this document exists, what problem it solves] + +## Scope + +[What is covered, what is explicitly out of scope] + +## References + +[Links to related requirements, specifications, standards] + +# [Content sections organized logically] +``` + #### Content Longevity Principles **Avoid Transitory Information**: Long-term documentation should not include information that becomes stale quickly: - **❌ Avoid**: Tool version numbers, specific counts (requirements, tests, files), current dates, "latest" references +- **❌ Examples**: "Currently using Node.js 18.2.1", "The system has 47 requirements", "As of March 2024" - **✅ Instead**: Reference auto-generated reports, use relative descriptions, focus on stable concepts +- **✅ Examples**: "See build_notes.md for current tool versions", "The requirements are organized by subsystem", + "The architecture follows..." **Exception**: Include transitory information only when documenting specific releases, version history, or when the temporal context is the document's purpose. @@ -91,6 +114,7 @@ when the temporal context is the document's purpose. ```markdown For more information, see [Continuous Compliance](https://github.com/demaconsulting/ContinuousCompliance). +Visit our website at https://docs.example.com/project-name ``` **CRITICAL**: Published documents (README.md and @@ -135,6 +159,8 @@ docs/ definition.yaml # Pandoc content definition title.txt # Document metadata introduction.md # Document introduction + sections/ # Individual content sections + sub-section.md # Sub-section document ``` #### Integration with CI/CD Pipeline @@ -162,6 +188,14 @@ graph TD D --> E[Database] ``` +### Benefits of Mermaid Integration + +- **Version Control**: Diagrams stored as text, enabling proper diff tracking +- **Maintainability**: Easy to update diagrams alongside code changes +- **Consistency**: Standardized diagram styling across all documentation +- **Tooling Support**: Rendered automatically in GitHub, documentation sites, and modern editors +- **Accessibility**: Text-based format supports screen readers and accessibility tools + ## Quality Gate Verification ### Documentation Linting Checklist diff --git a/.github/agents/test-developer.agent.md b/.github/agents/test-developer.agent.md index 1b2b1c5..4e6130e 100644 --- a/.github/agents/test-developer.agent.md +++ b/.github/agents/test-developer.agent.md @@ -5,7 +5,7 @@ tools: [edit, read, search, execute] user-invocable: true --- -# Test Developer Agent - TestResults +# Test Developer Agent Develop comprehensive unit and integration tests with emphasis on requirements coverage and Continuous Compliance verification. @@ -165,12 +165,69 @@ dotnet test --configuration Release --framework net8.0 --logger "trx;LogFileName --verbosity normal - name: Upload Test Results - uses: actions/upload-artifact@v8 + uses: actions/upload-artifact@v7 with: name: test-results path: TestResults/**/*.trx ``` +## Test Development Patterns + +### Comprehensive Test Coverage + +```csharp +[TestClass] +public class CalculatorTests +{ + [TestMethod] + public void Calculator_Add_PositiveNumbers_ReturnsSum() + { + // Happy path test + } + + [TestMethod] + public void Calculator_Add_NegativeNumbers_ReturnsSum() + { + // Edge case test + } + + [TestMethod] + public void Calculator_Divide_ByZero_ThrowsException() + { + // Error condition test + } + + [TestMethod] + public void Calculator_Divide_MaxValues_HandlesOverflow() + { + // Boundary condition test + } +} +``` + +### Mock and Dependency Testing + +```csharp +[TestMethod] +public void OrderService_ProcessOrder_ValidOrder_CallsPaymentService() +{ + // Arrange - Setup mocks and dependencies + var mockPaymentService = Substitute.For(); + var mockInventoryService = Substitute.For(); + var orderService = new OrderService(mockPaymentService, mockInventoryService); + + var testOrder = new Order { ProductId = 1, Quantity = 2, CustomerId = 123 }; + + // Act - Execute the system under test + var result = orderService.ProcessOrder(testOrder); + + // Assert - Verify interactions and outcomes + Assert.IsTrue(result.Success); + mockPaymentService.Received(1).ProcessPayment(Arg.Any()); + mockInventoryService.Received(1).ReserveItems(1, 2); +} +``` + ## Compliance Verification Checklist ### Before Completing Test Work diff --git a/.gitignore b/.gitignore index 48dc886..f5ac6cc 100644 --- a/.gitignore +++ b/.gitignore @@ -117,3 +117,4 @@ versionmark-*.json # Agent report files AGENT_REPORT_*.md +matrix.md diff --git a/AGENTS.md b/AGENTS.md index 1386733..544e37b 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -51,9 +51,9 @@ modification policies in header comments. ## Continuous Compliance Overview -This repository follows the DEMA Consulting Continuous Compliance approach -, which enforces quality -and compliance gates on every CI/CD run instead of as a last-mile activity. +This repository follows the DEMA Consulting Continuous Compliance + approach, which enforces quality and +compliance gates on every CI/CD run instead of as a last-mile activity. ### Core Principles diff --git a/docs/design/junit-serializer.md b/docs/design/junit-serializer.md index ae15d7b..c8e8ac5 100644 --- a/docs/design/junit-serializer.md +++ b/docs/design/junit-serializer.md @@ -75,7 +75,8 @@ When deserializing a JUnit document to a `TestResults` object: ### JUnit Round-Trip Fidelity JUnit XML does not have distinct elements for every `TestOutcome` value, so two known -fidelity limitations apply when round-tripping through JUnit: +fidelity limitations apply when round-tripping through JUnit. This satisfies requirement +`TestResults-Ser-RoundTrip` for JUnit, subject to these limitations: - **`Timeout` and `Aborted` outcomes are not preserved.** Both are serialized as an `error` child element (since JUnit has no distinct timeout or aborted element), and diff --git a/docs/design/serializer.md b/docs/design/serializer.md index 272794d..adf437b 100644 --- a/docs/design/serializer.md +++ b/docs/design/serializer.md @@ -53,7 +53,14 @@ The conversion algorithm: This design means that callers do not need to know or specify the format — they simply pass the raw content and receive a `TestResults` object. -Round-trip fidelity (serialize → deserialize → same data) is fully preserved for the -TRX format. For JUnit XML, two known limitations apply (see **JUnit Round-Trip Fidelity** -in the JUnitSerializer design document), satisfying requirement -`TestResults-Ser-RoundTrip`. +## Utf8StringWriter Helper + +The `Utf8StringWriter` class is an internal helper that extends `StringWriter` to +report UTF-8 as its encoding. When `XmlWriter` or `XmlSerializer` writes to a +`StringWriter`, it reads the writer's `Encoding` property to determine which XML +declaration encoding to emit. The default `StringWriter` reports UTF-16 (the +.NET string encoding), which would cause serializers to write `encoding="utf-16"` in the +XML declaration even when the resulting string is later converted to UTF-8 bytes. +`Utf8StringWriter` overrides the `Encoding` property to return `Encoding.UTF8`, so +the XML declaration correctly declares `encoding="UTF-8"`. It is used by both +`TrxSerializer.Serialize()` and `JUnitSerializer.Serialize()`. diff --git a/docs/design/test-outcome.md b/docs/design/test-outcome.md index d961fbf..11776f4 100644 --- a/docs/design/test-outcome.md +++ b/docs/design/test-outcome.md @@ -47,7 +47,8 @@ Returns `true` when the outcome falls into the *passed* category: - `Warning` All other outcomes return `false`. This satisfies requirements -`TestResults-Mdl-PassedOutcome`, `TestResults-Mdl-WarningOutcome`. +`TestResults-Mdl-PassedOutcome`, `TestResults-Mdl-PassedButRunAbortedOutcome`, +`TestResults-Mdl-WarningOutcome`. ### IsFailed() @@ -72,4 +73,6 @@ Returns `false` (i.e., the test was **not** executed) for the following outcomes Returns `true` for all other outcomes, including `Inconclusive`, `InProgress`, and `Disconnected`. This satisfies requirements `TestResults-Mdl-NotExecutedOutcome`, -`TestResults-Mdl-PendingOutcome`, `TestResults-Mdl-InconclusiveOutcome`. +`TestResults-Mdl-NotRunnableOutcome`, `TestResults-Mdl-PendingOutcome`, +`TestResults-Mdl-InconclusiveOutcome`, `TestResults-Mdl-CompletedOutcome`, +`TestResults-Mdl-InProgressOutcome`, `TestResults-Mdl-DisconnectedOutcome`. diff --git a/docs/design/trx-serializer.md b/docs/design/trx-serializer.md index 99b9c17..1fb562f 100644 --- a/docs/design/trx-serializer.md +++ b/docs/design/trx-serializer.md @@ -79,3 +79,10 @@ When deserializing a TRX document to a `TestResults` object: - Throws `InvalidOperationException` if the document structure is invalid: a `UnitTestResult` that references a non-existent `testId`, or the `TestDefinitions` section contains duplicate `UnitTest/@id` values + +### TRX Round-Trip Fidelity + +Round-trip fidelity (serialize → deserialize → same data) is fully preserved for the +TRX format. All `TestResults` and `TestResult` properties that are written during +serialization are read back identically during deserialization. This satisfies +requirement `TestResults-Ser-RoundTrip` for TRX. diff --git a/docs/reqstream/ots-buildmark.yaml b/docs/reqstream/ots-buildmark.yaml index 91f3ca8..8b82fc2 100644 --- a/docs/reqstream/ots-buildmark.yaml +++ b/docs/reqstream/ots-buildmark.yaml @@ -18,3 +18,6 @@ sections: tags: [ots] tests: - BuildMark_MarkdownReportGeneration + - BuildMark_GitIntegration + - BuildMark_IssueTracking + - BuildMark_KnownIssuesReporting diff --git a/docs/reqstream/ots-pandoctool.yaml b/docs/reqstream/ots-pandoctool.yaml new file mode 100644 index 0000000..da9aec2 --- /dev/null +++ b/docs/reqstream/ots-pandoctool.yaml @@ -0,0 +1,25 @@ +--- +# PandocTool OTS Software Requirements +# +# Requirements for the PandocTool document conversion tool. +# +# TODO: Self-validation support for demaconsulting.pandoctool is being worked on. +# Once available, uncomment the requirement below and link to the +# appropriate self-validation tests. + +sections: + - title: OTS Software Requirements + sections: + - title: PandocTool Requirements + # TODO: Add requirement when demaconsulting.pandoctool supports --validate + # requirements: + # - id: TestResults-OTS-PandocTool + # title: PandocTool shall convert markdown documentation to HTML for PDF generation. + # justification: | + # DemaConsulting.PandocTool wraps the Pandoc document converter to transform markdown + # design and requirements documents into HTML files used as input for WeasyPrint PDF + # generation. It runs in the documentation-generation job of the CI pipeline on + # Windows. + # tags: [ots] + # tests: + # - PandocTool_DocumentConversion diff --git a/docs/reqstream/ots-reqstream.yaml b/docs/reqstream/ots-reqstream.yaml index 98d1a10..aac64e0 100644 --- a/docs/reqstream/ots-reqstream.yaml +++ b/docs/reqstream/ots-reqstream.yaml @@ -18,4 +18,8 @@ sections: --enforce proves all requirements are covered and that ReqStream is functioning. tags: [ots] tests: + - ReqStream_RequirementsProcessing + - ReqStream_TraceMatrix + - ReqStream_ReportExport + - ReqStream_TagsFiltering - ReqStream_EnforcementMode diff --git a/docs/reqstream/ots-reviewmark.yaml b/docs/reqstream/ots-reviewmark.yaml index e730a5d..df307db 100644 --- a/docs/reqstream/ots-reviewmark.yaml +++ b/docs/reqstream/ots-reviewmark.yaml @@ -17,5 +17,11 @@ sections: results, so a successful pipeline run is evidence that ReviewMark executed without error. tags: [ots] tests: + - ReviewMark_VersionDisplay + - ReviewMark_HelpDisplay - ReviewMark_ReviewPlanGeneration - ReviewMark_ReviewReportGeneration + - ReviewMark_IndexScan + - ReviewMark_WorkingDirectoryOverride + - ReviewMark_Enforce + - ReviewMark_Elaborate diff --git a/docs/reqstream/ots-sarifmark.yaml b/docs/reqstream/ots-sarifmark.yaml index 1fb4fcc..6005193 100644 --- a/docs/reqstream/ots-sarifmark.yaml +++ b/docs/reqstream/ots-sarifmark.yaml @@ -19,3 +19,4 @@ sections: tests: - SarifMark_SarifReading - SarifMark_MarkdownReportGeneration + - SarifMark_Enforcement diff --git a/docs/reqstream/ots-sonarscanner.yaml b/docs/reqstream/ots-sonarscanner.yaml new file mode 100644 index 0000000..422ba97 --- /dev/null +++ b/docs/reqstream/ots-sonarscanner.yaml @@ -0,0 +1,26 @@ +--- +# SonarScanner OTS Software Requirements +# +# Requirements for the SonarScanner for .NET code analysis tool. +# +# TODO: Self-validation support for dotnet-sonarscanner is being worked on. +# Once available, uncomment the requirement below and link to the +# appropriate self-validation tests. + +sections: + - title: OTS Software Requirements + sections: + - title: SonarScanner Requirements + # TODO: Add requirement when dotnet-sonarscanner supports --validate + # requirements: + # - id: TestResults-OTS-SonarScanner + # title: SonarScanner shall upload code analysis results to SonarCloud. + # justification: | + # dotnet-sonarscanner wraps the build process (begin/end) to collect and upload + # code coverage, static analysis, and quality metrics to SonarCloud. SonarMark + # then retrieves those results from SonarCloud to generate the quality report. A + # successful SonarMark quality-gate retrieval is evidence that SonarScanner + # executed correctly and uploaded results to SonarCloud. + # tags: [ots] + # tests: + # - SonarMark_QualityGateRetrieval diff --git a/docs/reqstream/ots-weasyprinttool.yaml b/docs/reqstream/ots-weasyprinttool.yaml new file mode 100644 index 0000000..f053b9b --- /dev/null +++ b/docs/reqstream/ots-weasyprinttool.yaml @@ -0,0 +1,24 @@ +--- +# WeasyPrintTool OTS Software Requirements +# +# Requirements for the WeasyPrintTool PDF generation tool. +# +# TODO: Self-validation support for demaconsulting.weasyprinttool is being worked on. +# Once available, uncomment the requirement below and link to the +# appropriate self-validation tests. + +sections: + - title: OTS Software Requirements + sections: + - title: WeasyPrintTool Requirements + # TODO: Add requirement when demaconsulting.weasyprinttool supports --validate + # requirements: + # - id: TestResults-OTS-WeasyPrintTool + # title: WeasyPrintTool shall convert HTML documentation to PDF release artifacts. + # justification: | + # DemaConsulting.WeasyPrintTool wraps the WeasyPrint HTML-to-PDF converter to produce + # the design documentation and requirements PDF artifacts included in each release. + # It runs in the documentation-generation job of the CI pipeline on Windows. + # tags: [ots] + # tests: + # - WeasyPrintTool_PdfGeneration diff --git a/docs/reqstream/platform-requirements.yaml b/docs/reqstream/platform-requirements.yaml index 3eae848..7b38901 100644 --- a/docs/reqstream/platform-requirements.yaml +++ b/docs/reqstream/platform-requirements.yaml @@ -24,6 +24,7 @@ sections: tests: # Tests link to "windows" to ensure results come from Windows platform - "windows@TrxSerializer_Serialize_BasicTestResults_ProducesValidTrxXml" + - "windows@JUnitSerializer_Serialize_PassedTest_ProducesValidJUnitXml" - id: TestResults-Platform-Linux title: The library shall build and run on Linux platforms. @@ -33,6 +34,7 @@ sections: tests: # Tests link to "ubuntu" to ensure results come from Linux platform - "ubuntu@TrxSerializer_Serialize_BasicTestResults_ProducesValidTrxXml" + - "ubuntu@JUnitSerializer_Serialize_PassedTest_ProducesValidJUnitXml" - id: TestResults-Platform-MacOS title: The library shall build and run on macOS platforms. @@ -42,3 +44,4 @@ sections: tests: # Tests link to "macos" to ensure results come from macOS platform - "macos@TrxSerializer_Serialize_BasicTestResults_ProducesValidTrxXml" + - "macos@JUnitSerializer_Serialize_PassedTest_ProducesValidJUnitXml" diff --git a/docs/reqstream/unit-test-outcome.yaml b/docs/reqstream/unit-test-outcome.yaml index dc015e0..af63f58 100644 --- a/docs/reqstream/unit-test-outcome.yaml +++ b/docs/reqstream/unit-test-outcome.yaml @@ -97,3 +97,53 @@ sections: require attention, supporting a more nuanced test result classification. tests: - TestOutcome_IsPassed_PassedOutcome_ReturnsTrue + + - id: TestResults-Mdl-PassedButRunAbortedOutcome + title: The library shall support the PassedButRunAborted test outcome. + justification: | + The PassedButRunAborted outcome represents tests that passed individually but were part + of a test run that was subsequently aborted. This status is important for distinguishing + between tests that succeeded before an abort and those that failed, maintaining accurate + test result classification in TRX format. + tests: + - TestOutcome_IsPassed_PassedOutcome_ReturnsTrue + - TestOutcome_IsExecuted_AllOutcomes_ReturnsExpectedResult + + - id: TestResults-Mdl-NotRunnableOutcome + title: The library shall support the NotRunnable test outcome. + justification: | + The NotRunnable outcome represents tests that could not be executed due to configuration + issues, missing dependencies, or other environmental problems. This status is important + for identifying test infrastructure issues distinct from skipped tests, which is a key + distinction in TRX format. + tests: + - TestOutcome_IsExecuted_AllOutcomes_ReturnsExpectedResult + + - id: TestResults-Mdl-CompletedOutcome + title: The library shall support the Completed test outcome. + justification: | + The Completed outcome represents tests that finished execution, used by some test + frameworks to indicate completion without specifying pass or fail. This status is + important for compatibility with test frameworks that use this terminology and is + referenced in TRX ResultSummary elements. + tests: + - TestOutcome_IsExecuted_AllOutcomes_ReturnsExpectedResult + + - id: TestResults-Mdl-InProgressOutcome + title: The library shall support the InProgress test outcome. + justification: | + The InProgress outcome represents tests that are currently executing. This status is + important for test frameworks that report real-time test execution status and allows + tracking of long-running tests or tests that may have hung during execution. + tests: + - TestOutcome_IsExecuted_AllOutcomes_ReturnsExpectedResult + + - id: TestResults-Mdl-DisconnectedOutcome + title: The library shall support the Disconnected test outcome. + justification: | + The Disconnected outcome represents tests where the test agent became disconnected during + execution. This status is important for distributed test execution scenarios and helps + distinguish between test failures and infrastructure failures, which is critical for + accurate test result analysis in enterprise environments. + tests: + - TestOutcome_IsExecuted_AllOutcomes_ReturnsExpectedResult diff --git a/docs/reqstream/unit-test-results.yaml b/docs/reqstream/unit-test-results.yaml index 3ff0eb7..2d8d41d 100644 --- a/docs/reqstream/unit-test-results.yaml +++ b/docs/reqstream/unit-test-results.yaml @@ -18,5 +18,6 @@ sections: - TestResults_Id_Default_IsNotEmpty - TestResults_Id_TwoInstances_AreUnique - TestResults_Name_Default_IsEmpty + - TestResults_UserName_Default_IsEmpty - TestResults_Results_Default_IsNotNull - TestResults_Results_Default_IsEmpty diff --git a/requirements.yaml b/requirements.yaml index a91923f..508e0fa 100644 --- a/requirements.yaml +++ b/requirements.yaml @@ -19,3 +19,6 @@ includes: - docs/reqstream/ots-sarifmark.yaml - docs/reqstream/ots-sonarmark.yaml - docs/reqstream/ots-reviewmark.yaml + - docs/reqstream/ots-sonarscanner.yaml + - docs/reqstream/ots-pandoctool.yaml + - docs/reqstream/ots-weasyprinttool.yaml diff --git a/test/DemaConsulting.TestResults.Tests/IO/JUnitSerializerTests.cs b/test/DemaConsulting.TestResults.Tests/IO/JUnitSerializerTests.cs index 70ca17a..f3bfc17 100644 --- a/test/DemaConsulting.TestResults.Tests/IO/JUnitSerializerTests.cs +++ b/test/DemaConsulting.TestResults.Tests/IO/JUnitSerializerTests.cs @@ -1033,4 +1033,82 @@ public void JUnitSerializer_Deserialize_BareTestSuiteRoot_DeserializesCorrectly( Assert.AreEqual(TestOutcome.Passed, results.Results[0].Outcome); Assert.AreEqual(TimeSpan.FromSeconds(1.5), results.Results[0].Duration); } + + /// + /// Test that a NotRunnable outcome serializes as a skipped element + /// + [TestMethod] + public void JUnitSerializer_Serialize_NotRunnableOutcome_IncludesSkippedElement() + { + // Arrange - test result with NotRunnable outcome + var results = new TestResults + { + Name = "NotRunnableTests", + Results = + [ + new TestResult + { + Name = "NotRunnableTest", + ClassName = "MyTestClass", + Duration = TimeSpan.Zero, + Outcome = TestOutcome.NotRunnable, + ErrorMessage = "Test is not runnable" + } + ] + }; + + // Act + var xml = JUnitSerializer.Serialize(results); + Assert.IsNotNull(xml); + + // Assert - skipped element is present with message and skipped counter is incremented + var doc = XDocument.Parse(xml); + var testSuite = doc.Root?.Element("testsuite"); + Assert.IsNotNull(testSuite); + Assert.AreEqual("1", testSuite.Attribute("skipped")?.Value); + var testCase = testSuite.Element("testcase"); + Assert.IsNotNull(testCase); + var skipped = testCase.Element("skipped"); + Assert.IsNotNull(skipped); + Assert.AreEqual("Test is not runnable", skipped.Attribute("message")?.Value); + } + + /// + /// Test that a Pending outcome serializes as a skipped element + /// + [TestMethod] + public void JUnitSerializer_Serialize_PendingOutcome_IncludesSkippedElement() + { + // Arrange - test result with Pending outcome + var results = new TestResults + { + Name = "PendingTests", + Results = + [ + new TestResult + { + Name = "PendingTest", + ClassName = "MyTestClass", + Duration = TimeSpan.Zero, + Outcome = TestOutcome.Pending, + ErrorMessage = "Test is pending" + } + ] + }; + + // Act + var xml = JUnitSerializer.Serialize(results); + Assert.IsNotNull(xml); + + // Assert - skipped element is present with message and skipped counter is incremented + var doc = XDocument.Parse(xml); + var testSuite = doc.Root?.Element("testsuite"); + Assert.IsNotNull(testSuite); + Assert.AreEqual("1", testSuite.Attribute("skipped")?.Value); + var testCase = testSuite.Element("testcase"); + Assert.IsNotNull(testCase); + var skipped = testCase.Element("skipped"); + Assert.IsNotNull(skipped); + Assert.AreEqual("Test is pending", skipped.Attribute("message")?.Value); + } } diff --git a/test/DemaConsulting.TestResults.Tests/IO/TrxSerializerTests.cs b/test/DemaConsulting.TestResults.Tests/IO/TrxSerializerTests.cs index f6a0bd7..4d7d666 100644 --- a/test/DemaConsulting.TestResults.Tests/IO/TrxSerializerTests.cs +++ b/test/DemaConsulting.TestResults.Tests/IO/TrxSerializerTests.cs @@ -571,4 +571,59 @@ public void TrxSerializer_Serialize_ThenDeserialize_PreservesTestData() Assert.AreEqual(startTime.AddSeconds(6), skipped.StartTime); Assert.IsTrue(Math.Abs(skipped.Duration.TotalSeconds) < 0.001); } + + /// + /// Test that Deserialize throws InvalidOperationException for TRX with duplicate UnitTest IDs + /// + [TestMethod] + public void TrxSerializer_Deserialize_DuplicateUnitTestId_ThrowsInvalidOperationException() + { + // Arrange - TRX with two UnitTest elements sharing the same id + var trxWithDuplicateIds = + """ + + + + + + + + + + + + + + + """; + + // Act & Assert + Assert.ThrowsExactly(() => TrxSerializer.Deserialize(trxWithDuplicateIds)); + } + + /// + /// Test that Deserialize throws InvalidOperationException when a UnitTestResult references a non-existent testId + /// + [TestMethod] + public void TrxSerializer_Deserialize_NonExistentTestId_ThrowsInvalidOperationException() + { + // Arrange - TRX where the UnitTestResult/@testId has no matching UnitTest/@id + var trxWithMissingTestId = + """ + + + + + + + + + + + + """; + + // Act & Assert + Assert.ThrowsExactly(() => TrxSerializer.Deserialize(trxWithMissingTestId)); + } } diff --git a/test/DemaConsulting.TestResults.Tests/TestResultTests.cs b/test/DemaConsulting.TestResults.Tests/TestResultTests.cs index b9aa4e7..541e3e5 100644 --- a/test/DemaConsulting.TestResults.Tests/TestResultTests.cs +++ b/test/DemaConsulting.TestResults.Tests/TestResultTests.cs @@ -153,6 +153,26 @@ public void TestResult_ComputerName_Default_IsEnvironmentMachineName() Assert.AreEqual(expectedComputerName, result.ComputerName); } + /// + /// Tests that defaults to approximately the current UTC time + /// + [TestMethod] + public void TestResult_StartTime_Default_IsApproximatelyNow() + { + // Arrange - capture the time before and after creating a TestResult + var before = DateTime.UtcNow; + + // Act + var result = new TestResult(); + + var after = DateTime.UtcNow; + + // Assert - StartTime should be between before and after timestamps + Assert.IsTrue( + result.StartTime >= before && result.StartTime <= after, + $"StartTime {result.StartTime} should be between {before} and {after}"); + } + /// /// Tests that defaults to ///