com.wallstop-studios.dxmessaging 2.1.7 → 2.1.9

package/.llm/skills/testing/data-driven-tests.md

@@ -1,197 +0,0 @@
----
-title: "Data-Driven Tests with TestCaseSource"
-id: "data-driven-tests"
-category: "testing"
-version: "1.0.0"
-created: "2026-01-21"
-updated: "2026-01-21"
-
-source:
-  repository: "wallstop/unity-helpers"
-  files:
-    - path: "Tests/Runtime/SpriteSettingsTests.cs"
-    - path: "Tests/Runtime/ParabolaTests.cs"
-  url: "https://github.com/wallstop/unity-helpers"
-
-tags:
-  - "testing"
-  - "parameterized"
-  - "data-driven"
-  - "nunit"
-  - "test-cases"
-
-complexity:
-  level: "intermediate"
-  reasoning: "Requires understanding of NUnit's parameterized test features"
-
-impact:
-  performance:
-    rating: "low"
-    details: "No runtime impact; test execution time unchanged"
-  maintainability:
-    rating: "high"
-    details: "Reduces test duplication significantly"
-  testability:
-    rating: "high"
-    details: "Easy to add new test cases"
-
-prerequisites:
-  - "Understanding of NUnit attributes"
-
-dependencies:
-  packages: []
-  skills: []
-
-applies_to:
-  languages:
-    - "C#"
-  frameworks:
-    - "Unity"
-    - ".NET"
-  versions:
-    unity: ">=2021.3"
-
-aliases:
-  - "Parameterized tests"
-  - "TestCaseSource"
-  - "TestCase attribute"
-
-related:
-  - "test-categories"
-  - "test-diagnostics"
-  - "data-driven-tests-sources"
-  - "data-driven-tests-usage"
-
-status: "stable"
----
-
-# Data-Driven Tests with TestCaseSource
-
-> **One-line summary**: Use NUnit's `[TestCase]` and `[TestCaseSource]` attributes to run the same test logic with multiple inputs, reducing duplication and improving coverage.
-
-## Overview
-
-Data-driven testing separates test logic from test data:
-
-1. **Test method** defines what to test
-1. **Test cases** define the inputs and expected outputs
-
-This pattern eliminates copy-paste tests and makes adding new cases trivial.
-
-## Problem Statement
-
-```csharp
-// BAD: Duplicated test methods
-[Test]
-public void ParseIntegerZero()
-{
-    Assert.AreEqual(0, Parser.ParseInt("0"));
-}
-
-[Test]
-public void ParseIntegerPositive()
-{
-    Assert.AreEqual(42, Parser.ParseInt("42"));
-}
-
-[Test]
-public void ParseIntegerNegative()
-{
-    Assert.AreEqual(-5, Parser.ParseInt("-5"));
-}
-
-[Test]
-public void ParseIntegerWithSpaces()
-{
-    Assert.AreEqual(7, Parser.ParseInt("  7  "));
-}
-
-// 4 methods doing the same thing with different data!
-```
-
-## Solution
-
-### Using TestCase Attribute
-
-```csharp
-namespace WallstopStudios.UnityHelpers.Tests
-{
-    using NUnit.Framework;
-
-    [TestFixture]
-    public sealed class ParserTests
-    {
-        [Test]
-        [TestCase("0", 0)]
-        [TestCase("42", 42)]
-        [TestCase("-5", -5)]
-        [TestCase("  7  ", 7)]
-        [TestCase("999999", 999999)]
-        [TestCase("-999999", -999999)]
-        public void ParseIntegerHandlesValidInput(string input, int expected)
-        {
-            int result = Parser.ParseInt(input);
-            Assert.AreEqual(
-                expected,
-                result,
-                $"Input '{input}' should parse to {expected}, got {result}");
-        }
-
-        [Test]
-        [TestCase("")]
-        [TestCase("abc")]
-        [TestCase("12.34")]
-        [TestCase(null)]
-        public void ParseIntegerThrowsOnInvalidInput(string input)
-        {
-            Assert.Throws<FormatException>(
-                () => Parser.ParseInt(input),
-                $"Input '{input ?? "null"}' should throw FormatException");
-        }
-    }
-}
-```
-
-## Performance Notes
-
-- **Test Discovery**: Slight overhead for TestCaseSource reflection
-- **Execution**: Same as regular tests
-- **Memory**: Test cases are created once per test run
-
-## Best Practices
-
-### Do
-
-- Use `[TestCase]` for simple, inline cases (2-5 cases)
-- Use `[TestCaseSource]` for many cases or complex data
-- Include descriptive failure messages with all parameters
-- Use `SetName()` for human-readable test names
-- Group related test cases in named methods
-
-### Don't
-
-- Don't duplicate test logic across test methods
-- Don't forget to test edge cases (null, empty, bounds)
-- Don't use TestCaseSource for single test cases (overhead)
-- Don't make test case generation overly complex
-
-### Organizing Test Cases
-
-```csharp
-// Group by category
-private static IEnumerable<TestCaseData> HappyPathCases() { }
-private static IEnumerable<TestCaseData> EdgeCases() { }
-private static IEnumerable<TestCaseData> ErrorCases() { }
-
-// Or by feature
-private static IEnumerable<TestCaseData> ParsingCases() { }
-private static IEnumerable<TestCaseData> FormattingCases() { }
-private static IEnumerable<TestCaseData> ValidationCases() { }
-```
-
-## Related Patterns
-
-- [Test Categories](./test-categories.md) - Organizing tests
-- [Expressive Assertions](./expressive-assertions.md) - Clear failure messages
-- [Data-Driven Test Sources](./data-driven-tests-sources.md) - Advanced TestCaseSource patterns
-- [Data-Driven Test Usage Patterns](./data-driven-tests-usage.md) - Naming and diagnostics

package/.llm/skills/testing/git-workflow-robustness.md

@@ -1,369 +0,0 @@
----
-id: git-workflow-robustness
-title: "Git and Parser Robustness in CI/CD"
-description: "Best practices for robust git commands and markdown parsing in workflows"
-version: 1.0.0
-created: 2026-01-27
-updated: 2026-01-27
-status: stable
-category: testing
-
-tags:
-  - testing
-  - git
-  - ci-cd
-  - workflows
-  - markdown
-  - parsing
-
-complexity:
-  level: intermediate
-  prerequisites:
-    - Basic shell scripting
-    - Git fundamentals
-    - Markdown syntax
-
-impact:
-  performance:
-    rating: "none"
-    details: "CI/CD patterns only; no runtime impact"
-  testability:
-    rating: high
-    description: Prevents flaky tests from git edge cases
-  maintainability:
-    rating: medium
-    description: Improves parser reliability
-
-related:
-  - testing/comprehensive-test-coverage
-  - documentation/documentation-updates
----
-
-# Git and Parser Robustness in CI/CD
-
-## Overview
-
-This skill covers best practices for writing robust git commands in CI/CD pipelines and
-implementing reliable markdown parsers that handle edge cases correctly.
-
-## Solution
-
-## Git Command Edge Cases
-
-### Initial Commits and Single-Commit Repositories
-
-Git commands that reference previous commits can fail in specific repository states:
-
-```bash
-# DANGEROUS: Fails on initial commit (no HEAD~1 exists)
-git diff HEAD~1 -- path/to/file
-
-# DANGEROUS: Fails on single-commit repos
-git log --oneline -2  # May return fewer than 2 commits
-```
-
-#### Solution patterns
-
-```bash
-# Check commit count before referencing ancestors
-COMMIT_COUNT=$(git rev-list --count HEAD 2>/dev/null || echo "0")
-if [ "$COMMIT_COUNT" -gt 1 ]; then
-    git diff HEAD~1 -- path/to/file
-else
-    echo "No previous commit to compare against"
-fi
-```
-
-```bash
-# Use --first-parent and handle errors gracefully
-git diff HEAD~1 -- path/to/file 2>/dev/null || true
-```
-
-### Shallow Clones in CI Environments
-
-Many CI systems use shallow clones for speed. Commands that traverse history may fail:
-
-```bash
-# DANGEROUS: May fail with shallow clone
-git log --oneline --all
-
-# DANGEROUS: Ancestor references may not exist
-git merge-base main feature-branch
-```
-
-#### Solution patterns
-
-```bash
-# Fetch sufficient depth before operations
-git fetch --depth=50 origin main
-
-# Or unshallow if needed
-git fetch --unshallow 2>/dev/null || true
-```
-
-### Detached HEAD States
-
-CI systems often check out specific commits, creating detached HEAD states:
-
-```bash
-# DANGEROUS: Branch name queries fail in detached HEAD
-git branch --show-current  # Returns empty string
-
-# DANGEROUS: Assumes branch context
-git push origin HEAD:refs/heads/$(git branch --show-current)
-```
-
-#### Solution patterns
-
-```bash
-# Check for detached HEAD before branch operations
-CURRENT_BRANCH=$(git branch --show-current)
-if [ -z "$CURRENT_BRANCH" ]; then
-    echo "In detached HEAD state, using SHA instead"
-    CURRENT_REF=$(git rev-parse HEAD)
-else
-    CURRENT_REF=$CURRENT_BRANCH
-fi
-```
-
-### Empty Repository States
-
-Scripts must handle repositories with no commits:
-
-```bash
-# DANGEROUS: Fails on empty repos
-git log --oneline -1
-
-# DANGEROUS: HEAD doesn't exist
-git rev-parse HEAD
-```
-
-#### Solution patterns
-
-```bash
-# Check if HEAD exists before using it
-if git rev-parse HEAD >/dev/null 2>&1; then
-    git log --oneline -1
-else
-    echo "Repository has no commits"
-fi
-```
-
-### File Path Edge Cases
-
-Git commands with file paths can fail unexpectedly:
-
-```bash
-# DANGEROUS: Fails if path contains spaces
-git diff HEAD -- $FILE_PATH
-
-# DANGEROUS: Glob patterns may match nothing
-git diff HEAD -- *.md
-```
-
-#### Solution patterns
-
-```bash
-# Always quote variables containing paths
-git diff HEAD -- "$FILE_PATH"
-
-# Use nullglob or check pattern expansion
-shopt -s nullglob
-FILES=(*.md)
-if [ ${#FILES[@]} -gt 0 ]; then
-    git diff HEAD -- "${FILES[@]}"
-fi
-```
-
-### Line Ending Normalization: Index vs Working Tree
-
-`git add --renormalize` is commonly misunderstood. It updates the git **index** (staging area) based on `.gitattributes` rules but does **not** modify working tree files:
-
-```bash
-# MISLEADING: This does NOT fix files on disk
-git add --renormalize -- '*.md' '**/*.md'
-# After this command:
-# - Index: updated with normalized content
-# - Working tree: UNCHANGED (still has original line endings)
-# - Repository: left in a staged state
-```
-
-#### When to use each approach
-
-| Goal                                         | Command                           |
-| -------------------------------------------- | --------------------------------- |
-| Fix files on disk after cloning              | `node scripts/fix-eol.js`         |
-| Re-stage files after `.gitattributes` change | `git add --renormalize`           |
-| Fix files copied from external source        | `node scripts/fix-eol.js`         |
-| Verify line endings without changing         | `node scripts/check-eol.js`       |
-| Verify line endings before committing        | `node scripts/check-eol.js --all` |
-
-#### Working tree fix pattern
-
-```bash
-# Recommended: Fix working tree directly
-node scripts/fix-eol.js
-
-# Optional: Verbose mode shows what was fixed
-node scripts/fix-eol.js -v
-```
-
-## Markdown Inline Code Parsing
-
-### CommonMark Multi-Backtick Semantics
-
-CommonMark defines specific rules for code spans with multiple backticks:
-
-1. Opening and closing sequences must have the **same number of backticks**
-1. Content can contain backticks with fewer characters than the delimiter
-1. A single backtick inside double-backtick delimiters is literal text
-
-#### Examples
-
-````markdown
-`code` → <code>code</code>
-`code` → <code>code</code>
-`` `code` `` → <code>`code`</code>
-```a`b`` → <code>a`b</code> (opened with ``, closed with ``)
-`` a ` b ``     → <code>a` b</code>
-````
-
-### Parsing Algorithm
-
-A correct inline code parser must:
-
-1. Detect opening backtick sequences and count their length
-1. Search for a closing sequence of **exactly the same length**
-1. Handle nested or unmatched backticks as literal content
-1. Strip one leading and one trailing space when both are present
-
-**Key implementation requirements:**
-
-- Count opening backticks and search for closing sequence of **exactly the same length**
-- Verify the closing sequence isn't part of a longer backtick run
-- Strip one leading and trailing space when both are present (CommonMark rule)
-- Treat unmatched opening sequences as literal text
-
-### Common Parsing Pitfalls
-
-1. **Greedy matching**: Using regex like `` `[^`]+` `` fails on nested backticks
-1. **Ignoring backtick count**: Treating all backtick sequences as equivalent
-1. **Missing space stripping**: Not handling `` ` code ` `` correctly
-1. **Partial matches**: Matching ` `` ` inside ` ``` ` sequences
-
-## Test Coverage for Parsers
-
-### Edge Case Categories
-
-When testing parsers, cover these categories:
-
-| Category      | Examples                                       |
-| ------------- | ---------------------------------------------- |
-| Empty/minimal | `''`, `` ` ``, ` `` `                          |
-| Boundary      | Code at start/end, only code, adjacent spans   |
-| Nested        | ``` `` `nested` `` ```, unequal counts         |
-| Whitespace    | Leading/trailing spaces, only spaces, newlines |
-| Unicode       | `café`, emoji, zero-width characters           |
-
-### Data-Driven Test Patterns
-
-Use parameterized tests for comprehensive coverage:
-
-```javascript
-describe("inline code parsing", () => {
-  const testCases = [
-    // [input, expectedOutput, description]
-    ["`code`", [{ type: "code", content: "code" }], "simple code span"],
-    ["``a`b``", [{ type: "code", content: "a`b" }], "backtick in code"],
-    ["` a `", [{ type: "code", content: "a" }], "space stripping"],
-    [
-      "`a``b`",
-      [
-        { type: "code", content: "a" },
-        { type: "code", content: "b" }
-      ],
-      "adjacent spans"
-    ]
-  ];
-
-  test.each(testCases)("%s → %j (%s)", (input, expected, _desc) => {
-    expect(parseInlineCode(input)).toEqual(expected);
-  });
-});
-```
-
-### Property-Based Testing
-
-For parser robustness, use property-based tests with libraries like `fast-check`:
-
-- **Never throws**: Parser should handle any input without throwing
-- **Content preservation**: Total output length ≤ input length (accounting for delimiters)
-- **Idempotence**: Re-parsing output yields same structure
-
-## CI/CD Integration Patterns
-
-### Fail-Safe Git Operations
-
-Structure git operations in CI to handle all edge cases:
-
-```yaml
-# GitHub Actions example
-- name: Check for changes
-  id: changes
-  run: |
-    # Handle initial commit
-    if git rev-parse HEAD~1 >/dev/null 2>&1; then
-      CHANGED_FILES=$(git diff --name-only HEAD~1 HEAD)
-    else
-      # First commit - all files are "new"
-      CHANGED_FILES=$(git ls-tree --name-only -r HEAD)
-    fi
-    echo "files=$CHANGED_FILES" >> $GITHUB_OUTPUT
-```
-
-### Parser Testing in CI
-
-Ensure parser tests run with comprehensive edge cases:
-
-```yaml
-- name: Run parser tests
-  run: |
-    npm test -- --coverage --coverageThreshold='{"global":{"branches":90}}'
-```
-
-### Handling `grep` Exit Codes
-
-`grep` returns exit code 1 when no matches are found, which fails CI pipelines:
-
-```bash
-# DANGEROUS: Fails CI when no matches
-grep "pattern" file.txt
-
-# SAFE: Handle no-match case
-grep "pattern" file.txt || true
-
-# SAFE: Use count with fallback
-COUNT=$(grep -c "pattern" file.txt 2>/dev/null || echo "0")
-```
-
-## Validation Checklist
-
-Before merging code with git commands or parsers:
-
-- [ ] Git commands handle initial/empty commits
-- [ ] Git commands work with shallow clones
-- [ ] Git commands handle detached HEAD states
-- [ ] File paths are properly quoted
-- [ ] Parsers handle empty input
-- [ ] Parsers handle malformed/unmatched delimiters
-- [ ] Parsers handle unicode and special characters
-- [ ] Tests cover boundary conditions
-- [ ] Tests use data-driven patterns for edge cases
-- [ ] CI pipelines handle `grep` exit codes properly
-
-## See Also
-
-- [Comprehensive Test Coverage](../testing/comprehensive-test-coverage.md) - Detailed testing
-  strategies
-- [Documentation Updates](../documentation/documentation-updates.md) - Keeping docs in sync
-- [Shell Pattern Matching](../../context.md#shell-pattern-matching) - Main context file patterns