← Back to Skills Marketplace
ahmed181283

Integration Testing

by ahmed181283 · GitHub ↗ · v1.0.1 · MIT-0
cross-platform ⚠ suspicious
73
Downloads
0
Stars
0
Active Installs
2
Versions
Install in OpenClaw
/install integration-testing
Description
Automated integration testing with external services using testcontainers, wiremock, localstack. Use when developer needs to set up integration tests for tes...
README (SKILL.md)

Integration Testing with External Services

Quick Start

This skill helps you set up integration tests with external services:

  • Testcontainers: Run real services in Docker containers for testing
  • WireMock: Mock HTTP services and APIs
  • LocalStack: Local AWS services (S3) for testing without AWS dependency
  • SFTP: Integration testing with SFTP servers

When to Use This Skill

Use this skill when you need to:

  • Set up integration tests with external services
  • Test applications against real databases/message queues in isolation
  • Mock HTTP APIs for reliable testing
  • Test S3 integration without using real AWS resources
  • Configure automated integration test environments

Setup Options

Testcontainers Setup

For integration tests with real services:

# Basic testcontainers example
from testcontainers.postgres import PostgresContainer

def test_with_postgres():
    with PostgresContainer("postgres:15") as postgres:
        connection_string = postgres.get_connection_url()
        # Run tests with real PostgreSQL

See testcontainers-guide.md for detailed setup.

WireMock Setup

For mocking HTTP services:

# WireMock configuration example
from wiremock import WireMockServer

def test_with_wiremock():
    with WireMockServer() as wiremock:
        wiremock.stub_for(
            request_method="GET",
            request_url="/api/users",
            response_body='{"users": []}'
        )
        # Test against mocked API

See wiremock-patterns.md for common patterns.

LocalStack Setup

For testing S3 without AWS:

# LocalStack S3 testing example
import boto3
from localstack import start_localstack

def test_s3_with_localstack():
    with start_localstack(services=["s3"]) as localstack:
        s3 = boto3.client('s3', endpoint_url=localstack.endpoint_url)
        # Test S3 operations locally

See localstack-s3-config.md for S3 configuration.

SFTP Integration Testing

For testing SFTP connectivity and operations:

# SFTP integration test example
from paramiko import SSHClient

def test_sftp_operations():
    with SSHClient() as ssh:
        ssh.connect('sftp-server', username='test', password='test')
        sftp = ssh.open_sftp()
        # Test SFTP file operations

Available Templates

Ready-to-use test templates for common scenarios:

  • templates/testcontainers-python.py - Python testcontainers setup
  • templates/wiremock-http-tests.py - WireMock HTTP API tests
  • templates/localstack-s33-tests.py - LocalStack S3 integration tests
  • templates/sftp-integration-tests.py - SFTP integration testing

Helper Scripts

Setup scripts to initialize test environments:

  • scripts/setup_testcontainers.py - Configure testcontainers environment
  • scripts/init_wiremock.py - Initialize WireMock server
  • scripts/start_localstack.py - Start LocalStack services

Best Practices

  1. Container Management: Always use context managers for container lifecycle
  2. Port Conflicts: Configure ports to avoid conflicts with local services
  3. Cleanup: Ensure proper cleanup of resources in test teardown
  4. Environment Variables: Use env vars for configuration, avoid hardcoded values
  5. Parallel Testing: Design tests to run in parallel where possible

Getting Help

For detailed setup and patterns, see:

Security & Compliance

This skill is designed SOLELY for legitimate integration testing purposes in isolated development environments.

⚠️ Important Security Notes

  • Development Use Only: Never deploy test containers or services to production networks
  • Isolated Environments: All services run locally and are destroyed after testing
  • Educational Purpose: Designed to teach proper testing methodologies
  • Full Transparency: Source code is fully visible and auditable

For detailed security information, see SECURITY.md

Usage Guidance
This skill appears to do what it says (integration testing), but before running any setup scripts you should: 1) Inspect the scripts line-by-line (they modify ~/.bashrc, run pip install, curl downloads, and docker commands). 2) Do not run them on a production machine — use an isolated VM, disposable developer laptop, or CI runner. 3) Prefer running pip installs inside a virtualenv or container to avoid system-wide changes. 4) Undo or avoid TESTCONTAINERS_RYUK_DISABLED='true' unless you intentionally want containers to persist; enabling it prevents automatic cleanup and may leave running containers and exposed ports. 5) Check the Docker images (e.g., atmoz/sftp) and any external downloads (WireMock jar) you will pull. 6) If you want ephemeral behavior, remove lines that append to ~/.bashrc and avoid persistent LocalStack volume usage. If you are uncomfortable with these persistent changes, treat the repository as reference-only and copy the specific snippets you trust into your own controlled setup.
Capability Analysis
Type: OpenClaw Skill Name: integration-testing Version: 1.0.1 The skill bundle provides legitimate integration testing utilities but performs high-risk environment manipulations. Specifically, scripts/setup_testcontainers.py and scripts/start_localstack.py automatically append environment variable exports to the user's ~/.bashrc file, which is a form of persistence and environment manipulation. Additionally, scripts/init_wiremock.py downloads an external JAR file from Maven Central (repo1.maven.org) and executes it via Java, while templates/sftp-integration-tests.py uses a weak SSH host key policy (AutoAddPolicy). While these behaviors are plausibly intended for development convenience, the automated modification of shell profiles and remote artifact execution are risky capabilities.
Capability Assessment
Purpose & Capability
The name, description, SKILL.md, templates, and scripts are all consistent with an integration-testing helper for testcontainers, WireMock, LocalStack, and SFTP. The repository provides relevant guides and runnable scripts for those technologies. This dimension is broadly coherent.
Instruction Scope
The runtime instructions and included scripts do more than show examples: scripts perform network downloads (curl of a WireMock JAR), call pip to install packages, run Docker commands, start long-lived processes, and append environment configuration to the user's shell profile (~/.bashrc). That expands scope beyond passive examples to persistent system modification and package installation. Notably, setup_testcontainers sets TESTCONTAINERS_RYUK_DISABLED='true' (explicitly disabling automatic cleanup of containers), which contradicts the 'ephemeral' guidance in SKILL.md/SECURITY.md.
Install Mechanism
There is no install spec declared in the registry, but the provided scripts perform installs at runtime: pip installs (testcontainers, localstack, docker packages), curl download of a WireMock JAR from Maven Central, and docker run pulls (e.g., atmoz/sftp). The download sources are known registries (PyPI, Maven Central, Docker Hub), which is expected, but the scripts invoke system-wide installs rather than using isolated virtual environments. This is a medium-risk pattern because it modifies the host and downloads/extracts artifacts.
Credentials
The skill declares no required env vars, yet scripts append environment variables into ~/.bashrc (TESTCONTAINERS_HOST_OVERRIDE, TESTCONTAINERS_RYUK_DISABLED, AWS_ACCESS_KEY_ID/SECRET/REGION/ENDPOINT_URL_S3). The AWS values are the typical 'test' placeholders, but writing those and other config to the user's profile is persistent and intrusive. Disabling Ryuk (container cleanup) is disproportionate to a helper script and increases risk of leftover containers and resource exposure.
Persistence & Privilege
The scripts intentionally persist configuration by appending to ~/.bashrc and include examples for persistent LocalStack volumes (/tmp/localstack-data). They also include commands and defaults that can leave containers or services running (TESTCONTAINERS_RYUK_DISABLED = 'true', starting LocalStack or WireMock as background/long-running processes). While always:false (no forced inclusion), the skill's actions are persistent on the host if the scripts are executed.
How to Use
  1. Make sure OpenClaw is installed (local or Docker)
  2. Run the install command in chat: /install integration-testing
  3. After installation, invoke the skill by name or use /integration-testing
  4. Provide required inputs per the skill's parameter spec and get structured output
Version History
v1.0.1
Added comprehensive security context and warnings. Updated all templates with security disclaimers. Added SECURITY.md documentation explaining legitimate testing purpose. This skill is designed solely for integration testing in isolated environments.
v1.0.0
Initial release: Integration testing with testcontainers, WireMock, LocalStack, and SFTP
Metadata
Slug integration-testing
Version 1.0.1
License MIT-0
All-time Installs 0
Active Installs 0
Total Versions 2
Frequently Asked Questions

What is Integration Testing?

Automated integration testing with external services using testcontainers, wiremock, localstack. Use when developer needs to set up integration tests for tes... It is an AI Agent Skill for Claude Code / OpenClaw, with 73 downloads so far.

How do I install Integration Testing?

Run "/install integration-testing" in the OpenClaw or Claude Code chat to install it in one step — no extra setup required.

Is Integration Testing free?

Yes, Integration Testing is completely free, licensed under MIT-0. You can download, install and use it at no cost.

Which platforms does Integration Testing support?

Integration Testing is cross-platform and runs anywhere OpenClaw / Claude Code is available (cross-platform).

Who created Integration Testing?

It is built and maintained by ahmed181283 (@ahmed181283); the current version is v1.0.1.

💬 Comments