Refactor DslTerminologyAnalyzer into parsing and validation components

[Copilot]

Extracts parsing and validation logic from DslTerminologyAnalyzer into testable components, enabling terminology-level unit tests without analyzer overhead.

New Components

• TerminologyRule - Data model for blocked/preferred term pairs with case sensitivity
• DslRuleParser - Static XML parser returning List<TerminologyRule>
• TerminologyValidator - Validates identifiers against rules

API

// Parsing
var rules = DslRuleParser.Parse(xmlContent);

// Validation - returns null if valid, or the violated rule
var validator = new TerminologyValidator(rules);
var violation = validator.GetViolation("CustValue"); // returns rule blocking "Cust"

Tests

• 19 tests for DslRuleParser (XML parsing scenarios)
• 21 tests for TerminologyValidator (validation edge cases: MetaData/Metadata, FileName/Filename)

Existing analyzer-level tests unchanged.

Original prompt

Objective

Refactor the DslTerminologyAnalyzer into two parts to simplify testing and improve maintainability. The two components should be:

1. Parsing Component: Responsible for parsing out symbols (e.g., variable names, field names, property names, etc.).
2. Validation Component: Ensures the parsed symbols match the rules provided by the DSL XML.

Background & Context

Currently, Microsoft analyzer-level tests are used to validate the behavior of DslTerminologyAnalyzer. Although useful, such tests introduce unnecessary overhead and visual noise. A more structured approach would enable:

1. Maintaining existing analyzer-level tests (already completed).
2. Introducing terminology-level tests that focus on problematic keyword scenarios (e.g., handling keywords like Metadata, MetaData, Filename, FileName, etc.). This facilitates more modular and faster testing.

Key Deliverables

• Refactor the existing DslTerminologyAnalyzer into two distinguishable components: a Parsing Component and a Validation Component.
• Implement the necessary interfaces or plumbing to ensure these components can work together seamlessly.
• Add terminology-level unit tests to ensure:
  • Symbols are parsed correctly.
  • Rules are applied appropriately to the parsed symbols.

This refactor should maintain backward compatibility with existing analyzer-level tests while streamlining the process for adding new terminology-level tests.

This pull request was created as a result of the following prompt from Copilot chat.

Objective

Refactor the DslTerminologyAnalyzer into two parts to simplify testing and improve maintainability. The two components should be:

1. Parsing Component: Responsible for parsing out symbols (e.g., variable names, field names, property names, etc.).
2. Validation Component: Ensures the parsed symbols match the rules provided by the DSL XML.

Background & Context

Currently, Microsoft analyzer-level tests are used to validate the behavior of DslTerminologyAnalyzer. Although useful, such tests introduce unnecessary overhead and visual noise. A more structured approach would enable:

1. Maintaining existing analyzer-level tests (already completed).
2. Introducing terminology-level tests that focus on problematic keyword scenarios (e.g., handling keywords like Metadata, MetaData, Filename, FileName, etc.). This facilitates more modular and faster testing.

Key Deliverables

• Refactor the existing DslTerminologyAnalyzer into two distinguishable components: a Parsing Component and a Validation Component.
• Implement the necessary interfaces or plumbing to ensure these components can work together seamlessly.
• Add terminology-level unit tests to ensure:
  • Symbols are parsed correctly.
  • Rules are applied appropriately to the parsed symbols.

This refactor should maintain backward compatibility with existing analyzer-level tests while streamlining the process for adding new terminology-level tests.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Pressacco]

Implements:
#4

[Pressacco]

@copilot please don't over engineer this. The intent is to find a balance between:

• readability
• testability
• and having a manageable number of classes

[Copilot]

@copilot please don't over engineer this. The intent is to find a balance between:

• readability
• testability
  ...

Addressed in 8576bb2. Simplified to just 3 classes: TerminologyRule (data model), DslRuleParser (static parser), and TerminologyValidator (with simple GetViolation() returning null or the violated rule). Removed the ValidationResult class to reduce complexity.

[Pressacco]

Implements:

#4