Coverage reports ~97% line / 93% branch, but that number is flattering because DiffSection, DiffElement, and DiffOptions are all marked [ExcludeFromCodeCoverage], so real logic inside them is invisible. Concrete gaps found while reviewing:
Untested behavior (not just coverage — genuinely no assertions):
ElementSimilarityDiffElementAligner<T> has only a null-arg constructor test (ElementSimilarityDiffElementAlignerTests.cs). Its whole CalculateBestAlignment decision logic is exercised only indirectly through StringSimilarityDiffElementAligner, and only on tiny inputs — which is why the scoring bug (see separate issue) slipped through. Add direct tests with a controllable ElementSimilarity<T> delegate: insert-vs-delete-vs-modify selection, the modification threshold boundary, and inputs above/below the punt threshold.DiffOptions.ContextSize validation (throw on < 1) is untested — and the message is wrong (separate polish issue).DiffOptions.EnablePatienceOptimization = false path and ContextSize > 1 are never exercised. Both change LongestCommonSubsectionDiff/LongestCommonSubsequence.Find behavior and deserve dedicated diff tests.DiffSection.ToString() has five distinct branches, all [ExcludeFromCodeCoverage] and untested. If these strings matter, test them; if they don't, that's fine — but the exclusion hides it.BasicReplaceInsertDeleteDiffElementAligner<T> has no direct test (only reached via MutateToBeLike).
Suggestion: reconsider the blanket [ExcludeFromCodeCoverage] on types that contain conditional logic (DiffSection.ToString, DiffOptions.ContextSize). Excluding pure data records is reasonable; excluding types with branches just hides untested logic behind a green number.
Coverage reports ~97% line / 93% branch, but that number is flattering because
DiffSection,DiffElement, andDiffOptionsare all marked[ExcludeFromCodeCoverage], so real logic inside them is invisible. Concrete gaps found while reviewing:Untested behavior (not just coverage — genuinely no assertions):
ElementSimilarityDiffElementAligner<T>has only a null-arg constructor test (ElementSimilarityDiffElementAlignerTests.cs). Its wholeCalculateBestAlignmentdecision logic is exercised only indirectly throughStringSimilarityDiffElementAligner, and only on tiny inputs — which is why the scoring bug (see separate issue) slipped through. Add direct tests with a controllableElementSimilarity<T>delegate: insert-vs-delete-vs-modify selection, the modification threshold boundary, and inputs above/below the punt threshold.DiffOptions.ContextSizevalidation (throwon< 1) is untested — and the message is wrong (separate polish issue).DiffOptions.EnablePatienceOptimization = falsepath andContextSize > 1are never exercised. Both changeLongestCommonSubsectionDiff/LongestCommonSubsequence.Findbehavior and deserve dedicated diff tests.DiffSection.ToString()has five distinct branches, all[ExcludeFromCodeCoverage]and untested. If these strings matter, test them; if they don't, that's fine — but the exclusion hides it.BasicReplaceInsertDeleteDiffElementAligner<T>has no direct test (only reached viaMutateToBeLike).Suggestion: reconsider the blanket
[ExcludeFromCodeCoverage]on types that contain conditional logic (DiffSection.ToString,DiffOptions.ContextSize). Excluding pure data records is reasonable; excluding types with branches just hides untested logic behind a green number.