PluginBench
Skill
Pass
Audit score 90

bats-testing-patterns

wshobson/agents

Master Bash Automated Testing System (Bats) for comprehensive shell script testing.

What is bats-testing-patterns?

Bats is a testing framework for shell scripts that enables unit testing, test-driven development, and CI/CD integration. Use it when writing tests for shell utilities, validating behavior across shell environments, or building maintainable test suites.

  • Test error conditions and edge cases in shell scripts
  • Verify behavior across different shell dialects (bash, sh, dash)
  • Create reusable test fixtures and helper functions
  • Run tests in parallel for faster feedback
  • Integrate with CI/CD pipelines (GitHub Actions, Makefile)
  • Generate TAP (Test Anything Protocol) output for reporting

How to install bats-testing-patterns

npx skills add https://github.com/wshobson/agents --skill bats-testing-patterns
Prerequisites
  • Bats framework installed (npm install --global bats or package manager)
  • Basic knowledge of shell scripting and bash syntax
  • Test files organized in a tests/ directory
Claude Code
Cursor
Windsurf
Cline

How to use bats-testing-patterns

  1. 1.Create a test file with .bats extension in your tests/ directory
  2. 2.Write test functions using @test syntax with descriptive names
  3. 3.Use run command to execute functions and capture status and output
  4. 4.Assert on $status (exit code) and $output (stdout) in each test
  5. 5.Create a test_helper.sh file with common assertions and setup/teardown functions
  6. 6.Run bats tests/*.bats to execute all tests
  7. 7.Integrate into CI/CD by adding bats commands to your workflow or Makefile

Use cases

Good for
  • Writing unit tests for shell script functions and utilities
  • Implementing test-driven development (TDD) workflows for scripts
  • Setting up automated testing in GitHub Actions or other CI/CD systems
  • Testing shell compatibility across multiple interpreters
  • Validating error handling and edge cases before production deployment
Who it's for
  • Shell script developers
  • DevOps engineers building CI/CD pipelines
  • Teams practicing test-driven development
  • Maintainers of production shell utilities

bats-testing-patterns FAQ

How do I test if a command fails?

Use the run command to capture exit status, then assert [ "$status" -ne 0 ] to verify non-zero exit code. Check $output for error messages using [[ "$output" == *"pattern"* ]].

How do I skip tests conditionally?

Use skip or skip_if commands. For example: skip_if ! command -v jq &>/dev/null to skip if jq is not installed.

Can I run tests in parallel?

Yes, use bats tests/*.bats --parallel N where N is the number of parallel jobs. Ensure tests are independent and use unique temporary directories.

How do I test across different shells?

Run your script explicitly with different interpreters: bash script.sh, sh script.sh, dash script.sh. Use skip commands to handle shells that may not be available.

What should I clean up after tests?

Remove temporary files and directories in teardown functions or after each test. Use mktemp -d for test directories and rm -rf to clean them up.

Full instructions (SKILL.md)

Source of truth, from wshobson/agents.


name: bats-testing-patterns description: Master Bash Automated Testing System (Bats) for comprehensive shell script testing. Use when writing tests for shell scripts, CI/CD pipelines, or requiring test-driven development of shell utilities.

Bats Testing Patterns

Comprehensive guidance for writing comprehensive unit tests for shell scripts using Bats (Bash Automated Testing System), including test patterns, fixtures, and best practices for production-grade shell testing.

When to Use This Skill

  • Writing unit tests for shell scripts
  • Implementing test-driven development (TDD) for scripts
  • Setting up automated testing in CI/CD pipelines
  • Testing edge cases and error conditions
  • Validating behavior across different shell environments
  • Building maintainable test suites for scripts
  • Creating fixtures for complex test scenarios
  • Testing multiple shell dialects (bash, sh, dash)

Detailed patterns and worked examples

Detailed pattern documentation lives in references/details.md. Read that file when the navigation tier above is insufficient.

Testing Error Conditions

#!/usr/bin/env bats

@test "Function fails with missing file" {
    run my_function "/nonexistent/file.txt"
    [ "$status" -ne 0 ]
    [[ "$output" == *"not found"* ]]
}

@test "Function fails with invalid input" {
    run my_function ""
    [ "$status" -ne 0 ]
}

@test "Function fails with permission denied" {
    touch "$TMPDIR/readonly.txt"
    chmod 000 "$TMPDIR/readonly.txt"
    run my_function "$TMPDIR/readonly.txt"
    [ "$status" -ne 0 ]
    chmod 644 "$TMPDIR/readonly.txt"  # Cleanup
}

@test "Function provides helpful error message" {
    run my_function --invalid-option
    [ "$status" -ne 0 ]
    [[ "$output" == *"Usage:"* ]]
}

Testing with Dependencies

#!/usr/bin/env bats

setup() {
    # Check for required tools
    if ! command -v jq &>/dev/null; then
        skip "jq is not installed"
    fi

    export SCRIPT="${BATS_TEST_DIRNAME}/../bin/script.sh"
}

@test "JSON parsing works" {
    skip_if ! command -v jq &>/dev/null
    run my_json_parser '{"key": "value"}'
    [ "$status" -eq 0 ]
}

Testing Shell Compatibility

#!/usr/bin/env bats

@test "Script works in bash" {
    bash "${BATS_TEST_DIRNAME}/../bin/script.sh" arg1
}

@test "Script works in sh (POSIX)" {
    sh "${BATS_TEST_DIRNAME}/../bin/script.sh" arg1
}

@test "Script works in dash" {
    if command -v dash &>/dev/null; then
        dash "${BATS_TEST_DIRNAME}/../bin/script.sh" arg1
    else
        skip "dash not installed"
    fi
}

Parallel Execution

#!/usr/bin/env bats

@test "Multiple independent operations" {
    run bash -c 'for i in {1..10}; do
        my_operation "$i" &
    done
    wait'
    [ "$status" -eq 0 ]
}

@test "Concurrent file operations" {
    for i in {1..5}; do
        my_function "$TMPDIR/file$i" &
    done
    wait
    [ -f "$TMPDIR/file1" ]
    [ -f "$TMPDIR/file5" ]
}

Test Helper Pattern

test_helper.sh

#!/usr/bin/env bash

# Source script under test
export SCRIPT_DIR="${BATS_TEST_DIRNAME%/*}/bin"

# Common test utilities
assert_file_exists() {
    if [ ! -f "$1" ]; then
        echo "Expected file to exist: $1"
        return 1
    fi
}

assert_file_equals() {
    local file="$1"
    local expected="$2"

    if [ ! -f "$file" ]; then
        echo "File does not exist: $file"
        return 1
    fi

    local actual=$(cat "$file")
    if [ "$actual" != "$expected" ]; then
        echo "File contents do not match"
        echo "Expected: $expected"
        echo "Actual: $actual"
        return 1
    fi
}

# Create temporary test directory
setup_test_dir() {
    export TEST_DIR=$(mktemp -d)
}

cleanup_test_dir() {
    rm -rf "$TEST_DIR"
}

Integration with CI/CD

GitHub Actions Workflow

name: Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Install Bats
        run: |
          npm install --global bats

      - name: Run Tests
        run: |
          bats tests/*.bats

      - name: Run Tests with Tap Reporter
        run: |
          bats tests/*.bats --tap | tee test_output.tap

Makefile Integration

.PHONY: test test-verbose test-tap

test:
	bats tests/*.bats

test-verbose:
	bats tests/*.bats --verbose

test-tap:
	bats tests/*.bats --tap

test-parallel:
	bats tests/*.bats --parallel 4

coverage: test
	# Optional: Generate coverage reports

Best Practices

  1. Test one thing per test - Single responsibility principle
  2. Use descriptive test names - Clearly states what is being tested
  3. Clean up after tests - Always remove temporary files in teardown
  4. Test both success and failure paths - Don't just test happy path
  5. Mock external dependencies - Isolate unit under test
  6. Use fixtures for complex data - Makes tests more readable
  7. Run tests in CI/CD - Catch regressions early
  8. Test across shell dialects - Ensure portability
  9. Keep tests fast - Run in parallel when possible
  10. Document complex test setup - Explain unusual patterns