Agent skill

Create Test

by rundeck in rundeck/rundeck

Create backend tests for Rundeck (unit, API, functional). An agent skill from rundeck/rundeck.

Apache-2.0Auto-check passedTesting & QA

Install Create Test

skills CLI
$ npx skills add rundeck/rundeck --skill create-test -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install rundeck/rundeck create-test --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/rundeck/rundeck.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/create-test .claude/skills/create-test && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
create-test
GitHub stars
6.3k
Token cost
~3.2k tokens
SKILL.md length
796 words
Files
1
Skills in repo
10
Repo updated
First seen
Licence
Apache-2.0

At a glance

Create backend tests for Rundeck (unit, API, functional). An agent skill from rundeck/rundeck.

  • Works in 6 steps: Load Context → Identify Test Type → Write Unit Tests (Spock) → …
  • Tasks that involve Unit testing
  • SKILL.md covers When to Use, Process, Testing Philosophy and Checklist, plus 3 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Create Test is an agent skill from rundeck/rundeck. Create backend tests for Rundeck (unit, API, functional). Auto-loads testing guidelines. For frontend unit tests use write-jest-tests.

Its SKILL.md is about 3.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA, covering Unit testing, Integration testing and API testing. It works with Jest, Ansible and Docker. The repository describes itself as: Enable Self-Service Operations: Give specific users access to your existing tools, services, and scripts. The licence is Apache-2.0.

When your agent uses it

  • Tasks that involve Unit testing
  • Tasks that involve Integration testing
  • Tasks that involve API testing

Example prompts

  • “/create-test”

Requirements

  • Docker

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Load Context
  2. Identify Test Type
  3. Write Unit Tests (Spock)
  4. Write API Tests
  5. Write Functional Tests
  6. Run Tests

What it can do on your machine

Read from SKILL.md and the folder at commit 9c3c82c. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are groovy and bash).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • spockframework.org
    • testcontainers.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Create Test loads about 3.2k tokens when it runs. Until then it costs about 37 tokens; SKILL.md has 796 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~37
When it runs · the whole SKILL.md, loaded when a task matches
~3.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from rundeck/rundeck at commit 9c3c82c, republished under its Apache-2.0 licence (© rundeck). 796 words, ~3,202 tokens.

Download SKILL.mdSave it as .claude/skills/create-test/SKILL.md (or your agent's skills folder).
name
create-test
description
Create backend tests for Rundeck (unit, API, functional). Auto-loads testing guidelines. For frontend unit tests use write-jest-tests.

Create Test Skill

When to Use

  • Adding backend unit tests (Spock)
  • Implementing test-first workflow
  • Adding API tests for new/modified endpoints
  • Writing functional/integration tests
  • Fixing bugs (write failing test first, then fix)

For frontend unit tests: Use write-jest-tests skill

Process

Phase 1: Load Context

Automatically read:

  • .claude/docs/testing-guidelines.md - Complete testing guide (all test types)
  • .claude/docs/development-guidelines.md - Code standards, testing philosophy
Phase 2: Identify Test Type

Determine which test type(s) are needed:

Unit Tests - Functions, classes, services

  • Spock (Groovy)
  • Mock dependencies
  • Test in isolation

API Tests - REST endpoints

  • Testcontainers + Spock
  • Test API version requirements
  • Test request/response formats
  • Located in module tests

Functional Tests - Feature integration with Docker

  • Complete workflows with Rundeck in Docker
  • Use API for setup/validation
  • Test plugins, cluster, runners
  • Located in functional-test

Integration Tests - External systems

  • Docker containers (Testcontainers)
  • LDAP, Email, Ansible, etc.
  • Test external integrations
Phase 3: Write Unit Tests (Spock)
Spock Framework

Structure: Use given/when/then blocks

groovy
class UserServiceSpec extends Specification {
    
    def userService = new UserService()
    
    def "should return user when valid ID provided"() {
        given: "a valid user ID"
        def userId = 123
        
        when: "finding user by ID"
        def user = userService.findById(userId)
        
        then: "user is returned with correct ID"
        user != null
        user.id == userId
    }
    
    def "should throw exception when user not found"() {
        given: "an invalid user ID"
        def userId = 999
        
        when: "finding user by ID"
        userService.findById(userId)
        
        then: "exception is thrown"
        thrown(UserNotFoundException)
    }
}

Mocking with Spock:

groovy
def "should call external service"() {
    given: "a mocked external service"
    def mockService = Mock(ExternalService)
    def userService = new UserService(mockService)
    
    when: "getting user data"
    userService.getUserData(123)
    
    then: "external service is called once"
    1 * mockService.fetchData(123) >> "user data"
}

Data-Driven Tests with @Unroll:

groovy
@Unroll
def "should validate #scenario"() {
    expect:
    validator.isValid(input) == expected
    
    where:
    scenario        | input    | expected
    "valid email"   | "a@b.c"  | true
    "invalid email" | "abc"    | false
}
Phase 4: Write API Tests

Framework: Testcontainers + Spock

Purpose: Test Rundeck server API behavior with real server

CRITICAL: Test API version requirements

groovy
class ProjectApiSpec extends Specification {
    
    @Shared
    def container = new RundeckContainer()
    
    def "should return projects for API v44"() {
        when: "calling API v44"
        def response = client.get("/api/44/projects")
        
        then: "projects are returned"
        response.status == 200
        response.json.size() > 0
    }
    
    def "should reject for API v43"() {
        when: "calling API v43"
        def response = client.get("/api/43/projects")
        
        then: "request is rejected"
        response.status == 404
    }
}

Test Requirements:

  1. ✅ New behavior works with NEW API version
  2. ❌ New behavior does NOT work with OLD API version
  3. ✅ Error conditions return correct responses
  4. ✅ Success conditions work in all call patterns
  5. ✅ Test multiple content types (JSON, XML)
  6. ✅ Test multiple input formats
Phase 5: Write Functional Tests

Purpose: Test complete features/workflows with Rundeck running in Docker

Functional tests run in functional-test module using Testcontainers to launch Rundeck instances and verify functionality through APIs.

Test Annotations

@APITest - Standard functional tests

  • Extends BaseContainer
  • Single Rundeck instance in Docker
  • Tests features via API calls
Base Test Structure
groovy
package org.rundeck.functional.api.myfeature

import org.rundeck.util.common.jobs.JobUtils
import org.rundeck.annotations.APITest
import org.rundeck.util.container.BaseContainer

@APITest
class MyFeatureSpec extends BaseContainer {
    
    static final String TEST_PROJECT = "test-project"
    
    def setupSpec() {
        startEnvironment()  // Starts Rundeck in Docker
        setupProject(TEST_PROJECT)  // Creates test project
        
        // Optional: Configure feature flags
        def config = [
            [
                "key": "rundeck.feature.myFeature.enabled",
                "value": "true",
                "strata": "default"
            ]
        ]
        client.post("/config/save", config, Map)
        waitFeatureFlag("rundeck.feature.myFeature.enabled")
    }
    
    def cleanupSpec() {
        deleteProject(TEST_PROJECT)
    }
    
    def "feature works as expected"() {
        given: "test data setup"
        // Setup via API
        
        when: "performing action"
        def response = client.get("/api/endpoint", Map)
        
        then: "expected result"
        response.status == "success"
    }
}
Key Methods

Environment Setup:

  • startEnvironment() - Starts Rundeck container
  • setupProject(projectName) - Creates project
  • deleteProject(projectName) - Deletes project (cleanup)

API Calls:

  • client.get(path, Type) - GET request, parse as Type
  • client.post(path, body, Type) - POST request
  • get(path, Type) - Shorthand for client.get
  • doGet(path) - Raw HTTP GET
  • doPost(path, body) - Raw HTTP POST

Utilities:

  • waitFeatureFlag(key) - Wait for config to propagate
  • loadKey(path, value, type) - Create key storage entry
  • hold(seconds) - Wait fixed time (use sparingly)
  • jsonValue(body) - Parse JSON response

Job Operations (JobUtils):

  • JobUtils.createJob(project, yaml, client) - Import job
  • JobUtils.waitForExecution(status, execId, client, timeout) - Wait for execution
  • JobUtils.getExecutionOutputText(execId, client) - Get logs
Example: Basic API Test
groovy
@APITest
class SystemInfoSpec extends BaseContainer {
    
    def setupSpec() {
        startEnvironment()
    }
    
    def "system info returns valid response"() {
        when:
        def data = get("/system/info", Map)
        
        then:
        !data.error
        data.system.rundeck.apiversion.toInteger() >= 14
    }
}
Example: Plugin Integration Test
groovy
@APITest
class JiraPluginSpec extends BaseContainer {
    
    static final String TEST_PROJECT = "jira-test"
    
    def setupSpec() {
        startEnvironment()
        setupProject(TEST_PROJECT)
        
        // Configure Jira URL at system level
        def config = [
            ["key": "jira.url", "value": "https://jira.example.com", "strata": "default"]
        ]
        client.post("/config/save", config, Map)
        waitFeatureFlag("jira.url", "https://jira.example.com")
        
        // Store credentials
        loadKey("jira.pass", "test-password", "password")
    }
    
    def cleanupSpec() {
        deleteProject(TEST_PROJECT)
    }
    
    def "jira plugin reads system config"() {
        given: "a job using Jira plugin"
        def jobXml = """<joblist>
          <job>
            <name>jira test</name>
            <sequence>
              <command>
                <node-step-plugin type='jira-create-issue'>
                  <configuration>
                    <entry key='summary' value='Test Issue' />
                    <entry key='password' value='keys/jira.pass' />
                  </configuration>
                </node-step-plugin>
              </command>
            </sequence>
          </job>
        </joblist>"""
        
        when: "importing and running the job"
        def importResult = JobUtils.createJob(TEST_PROJECT, jobXml, client)
        def jobId = importResult.succeeded[0].id
        def response = doPost("/job/${jobId}/executions", ["loglevel": "DEBUG"])
        def execId = jsonValue(response.body()).id as String
        
        then: "job starts successfully"
        execId != null
        
        when: "waiting for completion"
        def exec = JobUtils.waitForExecution(
            ExecutionStatus.FAILED.state,  // Expected to fail (no real Jira)
            execId,
            client,
            WaitingTime.EXCESSIVE
        )
        
        then: "execution attempted to use system config URL"
        exec.status == 'failed'
        def fullLog = JobUtils.getExecutionOutputText(execId, client)
        fullLog.contains("jira.example.com")
    }
}
Important Patterns

Test Data Setup:

  • Use API to create test data (jobs, keys, config)
  • Don't rely on UI or manual setup
  • Use setupProjectArchiveDirectoryResource() for complex project setup

Waiting:

  • Use waitFeatureFlag() for config propagation
  • Use JobUtils.waitForExecution() for job completion
  • Avoid hold() except for cluster sync scenarios

Assertions:

  • Test through API responses
  • Verify job execution logs with getExecutionOutputText()
  • Check execution status, output, side effects

Cleanup:

  • Always cleanup in cleanupSpec()
  • Delete projects, jobs, keys created
  • Tests should not leave artifacts
Phase 6: Run Tests
bash
# Backend unit tests
./gradlew test

# Specific module
./gradlew :module-name:test

# API tests
./gradlew :functional-test:apiTest

# Functional tests
./gradlew :functional-test:test

Testing Philosophy

How do you know you fixed the problem?
  1. Write a test that exemplifies the problem
  2. Test should FAIL before implementing fix
  3. After fix, test should PASS
Show full SKILL.md (317 more words)Show less
How do you know new behavior works?

Update existing tests to cover new behaviors

What if code has no existing tests?

CRITICAL: Add missing tests for existing code FIRST

  1. Write tests for existing functionality
  2. Verify code works as expected
  3. You've now established baseline
  4. Future changes that break functionality → tests fail

Checklist

Before considering tests complete:

  • Test type identified (Unit, API, Functional)
  • Testing guidelines loaded and followed
  • Tests written before implementation
  • Tests follow proper patterns (given/when/then, Spock structure)
  • All tests pass locally
  • Unit tests: Proper mocking, test isolation
  • API tests: Version requirements tested, error conditions covered
  • Functional tests: Proper annotation (@APITest), cleanup in cleanupSpec()
  • Edge cases covered
  • Error conditions tested
  • No flaky tests introduced
  • Test names clearly describe what they test

Common Mistakes to Avoid

❌ Don't:

  • Skip tests for "simple" changes
  • Write implementation before tests
  • Test implementation details instead of behavior
  • Leave commented-out test code
  • Create flaky tests (random pass/fail)
  • Over-mock (test real behavior when possible)
  • Functional tests: Forget cleanupSpec() - leaves test data
  • Functional tests: Use hold() instead of proper waits
  • Functional tests: Create test data through UI (slow, brittle)
  • API tests: Test only new API version (must test old version rejects)

✅ Do:

  • Write test before implementation
  • Test edge cases and error conditions
  • Use clear test names that describe behavior
  • Keep tests simple and focused
  • Convert JUnit tests to Spock when modifying
  • Make tests independent (no execution order dependencies)
  • Unit tests: Mock at system boundaries, not internal interfaces
  • API tests: Test version requirements (new works, old rejects)
  • Functional tests: Setup via API, cleanup in cleanupSpec()
  • Functional tests: Use proper annotations (@APITest)

Integration with Other Skills

  • create-code: Use this skill when implementing test-first workflow
  • create-api-endpoint: API endpoints MUST have API tests (test version requirements)
  • create-plugin: Plugins should have unit tests for functionality

Resources

  • .claude/docs/testing-guidelines.md - Complete testing guide
  • .claude/docs/development-guidelines.md - Testing philosophy, code standards
  • Spock Framework - Groovy testing framework
  • Testcontainers - Docker containers for testing
  • Example tests: functional-test/src/test/groovy/

© rundeck, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/create-test of rundeck/rundeck.

Open the folder on GitHubat commit 9c3c82c

Compare with similar skills

Create Test next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Create Test compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Create Test this skillrundeck/rundeck6.3k—~3.2kAutomated safety check: PassApache-2.0
Integration Tests for pRESTprest/prest4.6k—~1.1kAutomated safety check: PassMIT
Designing TestsCloudAI-X/claude-workflow-v21.4k1 repos~1.5kAutomated safety check: PassMIT
Write Testsgrafana/synthetic-monitoring-app171—~1.2kAutomated safety check: PassAGPL-3.0
Running TestsNangoHQ/nango13k—~876Automated safety check: PassCustom licence
Slow TestsUKGovernmentBEIS/inspect_ai3k—~1.4kAutomated safety check: PassMIT

Similar skills

  • Guides writing and reviewing pREST Docker-based integration tests so every HTTP request is explained by step comments or table-driven descriptions.

    4.6k GitHub stars~1.1k tokensUpdated today
    Testing & QAAuto-check passed
  • Designing Tests

    CloudAI-X/claude-workflow-v2

    Designs and implements testing strategies for any codebase. An agent skill from CloudAI-X/claude-workflow-v2.

    1.4k GitHub starsUsed in 1 repo~1.5k tokens
    Testing & QAAuto-check passed
  • Write Tests

    grafana/synthetic-monitoring-app

    Official

    Write Jest integration and unit tests for the Grafana Synthetic Monitoring app using React Testing Library, MSW, and src/test helpers.

    171 GitHub stars~1.2k tokensUpdated today
    Testing & QAAuto-check passed
  • Running Tests

    NangoHQ/nango

    A skill your agent uses when running tests in the Nango monorepo - knows unit vs integration configs, vitest commands, Docker setup, and common test patterns

    13k GitHub stars~876 tokensUpdated today
    Testing & QAAuto-check passed
  • Slow Tests

    UKGovernmentBEIS/inspect_ai

    Run the gated test classes that plain pytest skips (slow Docker/sandbox tests, live model-provider API tests, flaky tests, trio variants).

    3k GitHub stars~1.4k tokensUpdated today
    Testing & QAAuto-check passed
  • NIC Testing Patterns

    nginx/kubernetes-ingress

    Testing conventions for the NGINX Ingress Controller repo: Go table-driven tests, mandatory snapshot regeneration, Helm tests and Python pytest integration tests.

    5.1k GitHub stars~2.8k tokensUpdated today
    Testing & QAAuto-check passed

More from rundeck/rundeck

All 10 skills in this repo
  • Backport PR

    rundeck/rundeck

    Backport commits from an existing GitHub Pull Request to a target branch and open a new backport PR.

    6.3k GitHub stars~3k tokensUpdated today
    Auto-check passed
  • Cve Remediation

    rundeck/rundeck

    Verify if a CVE affects the project and remediate it. An agent skill from rundeck/rundeck.

    6.3k GitHub stars~2.9k tokensUpdated today
    Auto-check passed
  • Generate standardized CONTEXT.md files for features. An agent skill from rundeck/rundeck.

    6.3k GitHub stars~2k tokensUpdated today
    Auto-check passed
  • I18n Vue Template

    rundeck/rundeck

    Internationalize Vue component templates by replacing all hardcoded strings with $t() calls and adding translations to i18n.ts or enUS.js.

    6.3k GitHub stars~523 tokensUpdated today
    Auto-check: notes
  • Onboard Contributor

    rundeck/rundeck

    Guide a new contributor through the rundeck OSS repo. An agent skill from rundeck/rundeck.

    6.3k GitHub stars~848 tokensUpdated today
    Auto-check passed
  • Write Jest Tests

    rundeck/rundeck

    Write Vue component unit tests. An agent skill from rundeck/rundeck.

    6.3k GitHub stars~486 tokensUpdated today
    Auto-check: notes

Categories

Questions about Create Test

What does Create Test do?

Create backend tests for Rundeck (unit, API, functional). An agent skill from rundeck/rundeck. Create Test is an agent skill from rundeck/rundeck. Create backend tests for Rundeck (unit, API, functional).

When should I use Create Test?

Create Test fits situations like: tasks that involve Unit testing; tasks that involve Integration testing; tasks that involve API testing.

How do I install Create Test in Claude Code?

Run `npx skills add rundeck/rundeck --skill create-test -a claude-code`. Or copy the skill folder (.claude/skills/create-test in rundeck/rundeck) into .claude/skills/create-test in your project. Claude Code loads it when a task matches its description.

How do I install Create Test in Codex?

Run `npx skills add rundeck/rundeck --skill create-test -a codex`. Or copy the skill folder (.claude/skills/create-test in rundeck/rundeck) into .agents/skills/create-test in your project. Codex loads it when a task matches its description.

Can I use Create Test in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add rundeck/rundeck --skill create-test -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/create-test, .gemini/skills/create-test, .github/skills/create-test and .opencode/skills/create-test in your project.

What does Create Test need to run?

SKILL.md names no scripts, command-line tools or credentials: Create Test is instructions for the agent only. Our summary lists: Docker.

Does Create Test access the network?

SKILL.md names 2 domains. As links in the text: spockframework.org and testcontainers.com. This is read from the text; nothing was executed.

Is Create Test safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Create Test use?

Create Test is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Create Test use?

About 3.2k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Create Test?

Skills that share tags, products or a category with Create Test: Integration Tests for pREST (prest/prest, 4.6k stars), Designing Tests (CloudAI-X/claude-workflow-v2, 1.4k stars), Write Tests (grafana/synthetic-monitoring-app, 171 stars) and Running Tests (NangoHQ/nango, 13k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Create Test?

rundeck (a GitHub organization) maintains it in rundeck/rundeck, which has 6,329 GitHub stars. The repository holds 10 skills in this directory. The repository was last updated on October 8, 2026.

Source: rundeck/rundeck on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.