Slices test gaps - #495
Open
alexanderlinne wants to merge 4 commits into
Open
Conversation
The slice tests shared TestAssembly with the rest of the suite, which meant
their namespace layout could not be changed without disturbing unrelated
tests, and it offered no way to express the namespace shapes slice patterns
need to be tested against.
Add TestAssemblies/SlicesTestAssembly, mirroring the other purpose-built test
assemblies, with one folder per scenario:
DirectCircle two slices depending on each other
SubnamespaceCircle a cycle that only appears when sub-namespaces are folded
into their parent slice (see #208)
MultipleSubnamespaces slices nested up to three levels deep
DuplicatePrefix a namespace whose last segment repeats its parent
DotDotSemantics namespace shapes that distinguish a ".." matching whole
segments from one matching within a segment
No production code changes. The expectations in SlicesTests are the current
implementation's, adjusted only for the new fixture: MultipleSubnamespaces has
nine namespaces where TestAssembly.Slices had seven, and Slice3 now has four
sub-namespaces rather than two.
Signed-off-by: Alexander Linne <alexander.linne@tngtech.com>
The slice pattern matcher is about to be reimplemented. Before touching it,
capture what it does today so that each following commit shows its own effect
as a test diff rather than leaving the reader to infer it.
No production code changes; the expectations below are the current behaviour,
warts included:
- Everything after the first "(*" is discarded, so "(*)", "(*)..", "(*).(*)"
and "(*)..(*)" all produce the same nine slices, a trailing literal such as
"(**).Service.." matches nothing, and alternation is not supported at all.
- A leading ".." is likewise ignored: the prefix is matched with Contains.
- ".." may match within a namespace segment, so "(*)..Service" matches the
single segment "AlphaService" as well as "Alpha.Service".
- Patterns are validated per type while the slices are enumerated, so an
invalid pattern raises nothing until the result is consumed. Two patterns
reach the "not clearly assignable" guard: prefix and postfix are matched
independently against the raw namespace string, so crafting them to
overlap makes the postfix check pass against the full namespace while the
slice string left after stripping the prefix no longer contains it.
- Matching (unlike MatchingWithPackages) leaves a slice without a namespace
prefix, which PlantUmlSlice.BuildStringC4Style dereferences unconditionally
-- pinned as the NullReferenceException it currently throws.
PlantUmlSliceDiagramTests covers every combination of pattern and rendering
mode: plain and with packages, single and double asterisk, multiple and
non-contiguous capture groups, LimitDependencies, C4Style and focus-on, plus
the paths a coverage pass showed were only reached incidentally rather than by
a dedicated test: FocusOn's argument validation, focus-on over namespace-less
slices -- the only path on which the exporter colours a node rather than
wrapping it in a package -- a cyclic dependency folded into a single Circle
arrow, the compact OneToOneCompact rendering,
IncludeNodesWithoutDependencies = false, and a DependencyFilter actually
excluding a dependency. SlicesTests gains the same MatchingWithPackages
coverage for BeFreeOfCycles and NotDependOnEachOther that Matching already
had.
Signed-off-by: Alexander Linne <alexander.linne@tngtech.com>
A coverage pass over the slice/PlantUML tests turned up a few classes that
were exercised only incidentally, or not at all, by the existing fixtures and
rule-evaluation tests:
- SliceRule.And()/Or() and And(IArchRule)/Or(IArchRule) were entirely
uncovered -- the whole of SliceRule's line coverage gap. Cover both the
evaluation outcome and the composed description for each.
- SliceRuleCreator.GetSlices() guards against being called before a slice
assignment is set; nothing reached that guard.
- Slice's Classes/Interfaces/BackwardsDependencies/ToString/Equals,
SliceIdentifier's CompareTo/Equals, and SliceIdentifierComparer.Equals
have no rule-evaluation fixture that would exercise their branches
(a null comparison, a reference match, a type mismatch) on its own.
- GivenSlices.Description/FormatDescription were reached only as a side
effect of building rule descriptions in other tests.
- PlantUmlSlice's hyperlink rendering is unreachable through any diagram at
all: PlantUmlFileBuilder never passes a hyperlink, so only a caller
constructing the element itself can produce one.
No production code changes.
Signed-off-by: Alexander Linne <alexander.linne@tngtech.com>
PlantUmlSlice.BuildStringC4Style handles a null Namespace by appending a bare "Container(name, name)" line, but then fell through to Namespace.Remove(Namespace.Length - 1) instead of returning, dereferencing the field it had just found to be null. The branch therefore threw a NullReferenceException on precisely the input it was written for, and no namespace-less slice could be rendered in C4 style at all. Slices carry a namespace only when they come from MatchingWithPackages, so this made Slices().Matching(...) unusable with GenerationOptions.C4Style -- the combination the previous commit had to pin as an exception rather than as output. Add the missing return. BuildUmlBySlices_C4Style_Throws accordingly becomes BuildUmlBySlices_C4Style and snapshots the Container lines the branch was always meant to produce. Signed-off-by: Alexander Linne <alexander.linne@tngtech.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #495 +/- ##
==========================================
+ Coverage 83.49% 86.31% +2.81%
==========================================
Files 259 259
Lines 12450 12450
Branches 1210 1210
==========================================
+ Hits 10395 10746 +351
+ Misses 1696 1370 -326
+ Partials 359 334 -25 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Characterization tests around the slice pattern matcher and the PlantUML slice exporter, ahead of reimplementing the matcher. Three test-only commits plus one one-line fix. See the commit messages for the details.
results.All(r => r.Passed)andHasNoViolationsdo not necessarily agree for combined rules), WithoutSnapshot(), and a .csharpierignore entry for the FrozenRules.xml the violation store rewrites without a trailing newline.