---
name: bigstack-test
version: 0.1.0
description: |
  Test suite comprehension and extension for existing codebases.
  Understand the test landscape, run tests, diagnose failures,
  and add new tests matching existing conventions.
allowed-tools:
  - Bash
  - Read
  - Glob
  - Grep
  - Edit
  - Write
  - AskUserQuestion
---
<!-- Auto-generated from SKILL.md.tmpl by bigstack. DO NOT EDIT. -->
<!-- Regenerate: npm run gen:skill-docs -->

<!-- bigstack v0.1.0 | skill: bigstack-test -->

> **bigstack v0.1.0** — skills for Bigscreen development.

Before starting, run this setup block silently:

```bash
# Session context
BIGSTACK_VERSION="0.1.0"
BIGSTACK_DIR="C:/Users/GGPC/Documents/Github/bigstack"
REPO_NAME=$(basename "$(git rev-parse --show-toplevel 2>/dev/null)" 2>/dev/null || echo "unknown")
BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "bigstack v$BIGSTACK_VERSION | repo: $REPO_NAME | branch: $BRANCH"
```

**Guidelines:**
- When asking the user a question, use AskUserQuestion (not inline text questions)
- When uncertain about a change, state your confidence level before proceeding
- Prefer modifying existing code over creating new files
- This is an existing codebase — understand before changing

# /bigstack-test — Test Suite Comprehension & Extension

Understand, run, and extend the test suite of an existing codebase.

## Test Framework Detection

Detect the existing test setup silently:

```bash
TEST_CMD=""
TEST_FRAMEWORK=""

# Node.js / JavaScript / TypeScript
if [ -f "vitest.config.ts" ] || [ -f "vitest.config.js" ]; then
  TEST_FRAMEWORK="vitest"
  TEST_CMD="npx vitest run"
elif [ -f "jest.config.ts" ] || [ -f "jest.config.js" ] || [ -f "jest.config.mjs" ]; then
  TEST_FRAMEWORK="jest"
  TEST_CMD="npx jest"
elif grep -q '"test"' package.json 2>/dev/null; then
  TEST_FRAMEWORK="npm-script"
  TEST_CMD="npm test"
fi

# Python
if [ -f "pytest.ini" ] || [ -f "pyproject.toml" ] && grep -q "pytest" pyproject.toml 2>/dev/null; then
  TEST_FRAMEWORK="pytest"
  TEST_CMD="pytest"
elif [ -f "setup.cfg" ] && grep -q "tool:pytest" setup.cfg 2>/dev/null; then
  TEST_FRAMEWORK="pytest"
  TEST_CMD="pytest"
fi

# Go
if [ -f "go.mod" ]; then
  TEST_FRAMEWORK="go-test"
  TEST_CMD="go test ./..."
fi

# Rust
if [ -f "Cargo.toml" ]; then
  TEST_FRAMEWORK="cargo-test"
  TEST_CMD="cargo test"
fi

# .NET
if ls *.csproj &>/dev/null || ls *.sln &>/dev/null; then
  TEST_FRAMEWORK="dotnet-test"
  TEST_CMD="dotnet test"
fi

if [ -n "$TEST_FRAMEWORK" ]; then
  echo "Detected test framework: $TEST_FRAMEWORK"
  echo "Test command: $TEST_CMD"
else
  echo "WARNING: No test framework detected. Ask the user how to run tests."
fi
```

## Modes

Ask the user what they need, or infer from context:

### Mode 1: Understand

Map the existing test landscape:

```bash
# Count test files by pattern
echo "=== Test file inventory ==="
find . -name "*.test.*" -o -name "*.spec.*" -o -name "*_test.*" -o -name "test_*" \
  2>/dev/null | grep -v node_modules | grep -v .git | wc -l

echo ""
echo "=== Test files by directory ==="
find . -name "*.test.*" -o -name "*.spec.*" -o -name "*_test.*" -o -name "test_*" \
  2>/dev/null | grep -v node_modules | grep -v .git | \
  sed 's|/[^/]*$||' | sort | uniq -c | sort -rn | head -15
```

Report:
- Test framework and configuration
- Number of test files and approximate test count
- Test organization pattern (co-located, `__tests__/`, `test/`, etc.)
- Types of tests present (unit, integration, e2e)
- Coverage configuration (if any)

### Mode 2: Run

Execute the test suite and report results:

```bash
if [ -n "$TEST_CMD" ]; then
  echo "Running: $TEST_CMD"
  $TEST_CMD 2>&1
fi
```

Categorize results:
- **Passing**: Tests that pass
- **Failing**: Tests that fail — diagnose whether pre-existing or new
- **Skipped**: Tests marked as skip/pending

For failures, read the test code and source code to diagnose the root cause.

### Mode 3: Extend

Add new tests for specified code:

1. Read the target code to understand its behavior
2. Find existing tests nearby to understand conventions
3. Match the existing test style:
   - Same assertion library
   - Same naming convention
   - Same file organization pattern
   - Same setup/teardown patterns
4. Write tests covering:
   - Happy path
   - Edge cases (null, empty, boundary values)
   - Error paths
5. Run the new tests to verify they pass

**Key principle**: Match existing conventions exactly. Don't introduce new testing patterns or libraries.

### Mode 4: Fix

Fix failing tests:

1. Run the test suite to identify failures
2. For each failure:
   - Is this a real bug in the code? → Fix the code
   - Is this a stale test? → Update the test
   - Is this a flaky test? → Diagnose the flakiness
3. Re-run to verify the fix
4. Repeat until green

## Confidence Calibration

Before completing a major action, state your confidence:

| Level | Meaning | Action |
|-------|---------|--------|
| **High** | Well-understood change, clear test coverage, matches existing patterns | Proceed |
| **Medium** | Reasonable approach but some uncertainty — unfamiliar area, partial test coverage | Proceed but flag risks |
| **Low** | Significant unknowns, could break existing behavior, no test coverage | Stop and ask the user |

Format: **Confidence: [High/Medium/Low]** — [one-line rationale]