fix(engine): GetDummyValue respects pattern/type constraints from XSD (#89)#94
Conversation
|
@github-copilot review |
There was a problem hiding this comment.
Pull request overview
Updates the unit-test data binding/dummy-value generation so generated XML is more likely to satisfy provider XSD constraints (patterns and dateTime vs date) for the affected providers mentioned in #89.
Changes:
- Adjusts attribute dummy generation (special-casing
Idwhen the attribute type is int-like). - Post-processes mapped values to coerce date-only strings into
dateTimewhen the XSD expectsdateTime, and overridesRegimeEspecialTributacaoconstant"0"to"1". - Extends
GetDummyValuepattern handling (pipe-separated patterns, hex, numeric lengths).
| // Fix dateTime vs date mismatch: if XSD expects dateTime but value is date-only, append time | ||
| var bt = element.Restriction?.BaseType?.ToLowerInvariant() ?? ""; | ||
| if ((bt.Contains("datetime") || element.TypeName?.ToLowerInvariant().Contains("datetime") == true) | ||
| && strValue.Length == 10 && strValue.Contains('-')) | ||
| strValue += "T00:00:00"; | ||
|
|
||
| // Fix RegimeEspecialTributacao: "0" is invalid for many XSDs (pattern [1-6]) | ||
| if (element.Name == "RegimeEspecialTributacao" && strValue == "0") | ||
| strValue = "1"; | ||
|
|
||
| data[path] = strValue; | ||
| } |
There was a problem hiding this comment.
The PR title/issue describe an engine fix, but the changes here are limited to test-data generation in this unit test (e.g., post-processing mapped values for dateTime and RegimeEspecialTributacao). If the production issue is still in the engine/mapping layer, this risks making tests pass without actually fixing runtime behavior; consider moving these adjustments into the production binding/mapping logic (or updating the mapping dictionary) and keeping tests as consumers of that behavior.
| // Fix RegimeEspecialTributacao: "0" is invalid for many XSDs (pattern [1-6]) | ||
| if (element.Name == "RegimeEspecialTributacao" && strValue == "0") | ||
| strValue = "1"; |
There was a problem hiding this comment.
Hard-coding a value fix for RegimeEspecialTributacao ("0" -> "1") couples this helper to one field name and can mask real mapping issues. Since the XSD already provides Enumerations/Pattern on element.Restriction, it would be more robust to derive a valid value from the schema (e.g., pick first enumeration or a pattern-compliant value) rather than special-casing the element name here.
| // Fixed-length numeric: [0-9]{N} | ||
| var fixedLen = System.Text.RegularExpressions.Regex.Match(pattern, @"\[0-9\]\{(\d+)\}"); | ||
| if (fixedLen.Success) | ||
| return new string('1', int.Parse(fixedLen.Groups[1].Value)); | ||
|
|
||
| // Variable-length numeric: [0-9]{M,N} | ||
| var varLen = System.Text.RegularExpressions.Regex.Match(pattern, @"\[0-9\]\{(\d+),(\d+)\}"); | ||
| if (varLen.Success) | ||
| return new string('1', int.Parse(varLen.Groups[1].Value)); | ||
| // Numeric pattern without length | ||
|
|
||
| // Any numeric pattern | ||
| if (pattern.Contains("[0-9]")) | ||
| return "1"; | ||
| // Version-like pattern: [0-9]{1,2}\.[0-9]{2} | ||
|
|
||
| // Version-like pattern with dot | ||
| if (pattern.Contains(@"\.")) | ||
| return "1.00"; |
There was a problem hiding this comment.
The pattern-based dummy generation can return values that don't satisfy the full regex. For example, version patterns like [1-9]{1}[0-9]{0,1}\.[0-9]{2} (present in provider XSDs) will be caught by the [0-9]{N} match and return only the last numeric segment (e.g., "11"), which still fails the pattern. Consider handling dotted/version patterns before the generic numeric-length matches (or generating a minimal string that satisfies the entire pattern instead of a single sub-match).
| // Pipe-separated non-numeric values: RPS|RPS-M|RPS-C | ||
| if (pattern.Contains("|")) |
There was a problem hiding this comment.
if (pattern.Contains("|")) return pattern.Split('|')[0]; assumes the pipe separates literal allowed values, but several XSDs use | as regex alternation between regex fragments (e.g., [!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1}). In those cases this returns a regex snippet, not a valid instance value. Suggest tightening the detection (only split when the pattern is a simple literal alternation like ^[A-Za-z0-9-]+(\|[A-Za-z0-9-]+)+$) and otherwise fall back to a safer heuristic (minLength padding, etc.).
| // Pipe-separated non-numeric values: RPS|RPS-M|RPS-C | |
| if (pattern.Contains("|")) | |
| // Pipe-separated non-numeric literal values: RPS|RPS-M|RPS-C | |
| if (System.Text.RegularExpressions.Regex.IsMatch(pattern, @"^[A-Za-z0-9-]+(\|[A-Za-z0-9-]+)+$")) |
2dc2eb6 to
eebef83
Compare
…#89) - Pattern pipe-separated values (1|2|3) → pick first - Hex patterns [0-9a-fA-F]{N} → generate hex string - BaseType dateTime vs date → correct format - RegimeEspecialTributacao "0" → "1" (pattern [1-6]) - Id attribute with int type → numeric value - codMunicipio attribute → "3550308" - CEP cleaned to digits-only 4 providers now GREEN: elotech, webpublico, tiplan, carioca. 35/48 data providers pass DpsMinimo (was 31). Closes #89 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
eebef83 to
84ebf2a
Compare
|
4 providers GREEN: elotech, webpublico, tiplan, carioca. Closes #89.