wiremock-standalone-docker

$npx mdskill add giuseppe-trisciuoglio/developer-kit/wiremock-standalone-docker

Runs WireMock as a standalone Docker container for mocking APIs.

  • Mocks external APIs during integration and end-to-end testing.
  • Depends on Docker Compose and WireMock Docker image.
  • Generates stub mappings and simulates error conditions based on test needs.
  • Delivers a running mock server with configurable endpoints and responses.

SKILL.md

.github/skills/wiremock-standalone-dockerView on GitHub ↗
---
name: wiremock-standalone-docker
description: Provides patterns and configurations for running WireMock as a standalone Docker container. Generates mock HTTP endpoints, creates stub mappings for testing, validates integration scenarios, and simulates error conditions. Use when you need to mock APIs, create a mock server, stub external services, simulate third-party APIs, or fake API responses for integration testing.
allowed-tools: Read, Write, Edit, Bash, Glob, Grep
---

# WireMock Standalone Docker Skill

## Overview

Provides patterns for running WireMock as a standalone Docker container to mock external APIs during integration and end-to-end testing. Runs WireMock as a separate service that simulates real API behavior for testing HTTP clients, retry logic, and error handling.

## When to Use

Use when you need to:
- Mock external APIs during integration or end-to-end testing
- Simulate error conditions (timeouts, 5xx, rate limiting) without real services
- Test HTTP client configurations, retry logic, and error handling
- Create portable, reproducible test environments
- Validate API contracts before implementing the real service

## Instructions

### Step 1: Set Up Docker Compose

Create a `docker-compose.yml` with WireMock 3.5.2, port mapping, and volume mounts for mappings and files:

```yaml
version: "3.8"
services:
  wiremock:
    image: wiremock/wiremock:3.5.2
    ports:
      - "8080:8080"
    volumes:
      - ./wiremock:/home/wiremock
    command: ["--global-response-templating"]
```

### Step 2: Create Directory Structure

Create the WireMock configuration directories:

```
wiremock/
├── mappings/   # JSON stub definitions
└── __files/   # Response body files
```

### Step 3: Define API Mappings

Create JSON stub files in `wiremock/mappings/` for each scenario:

- **Success**: Return 200 with JSON body
- **Not Found**: Return 404
- **Server Error**: Return 500
- **Timeout**: Use `fixedDelayMilliseconds`
- **Rate Limit**: Return 429 with Retry-After header

### Step 4: Start WireMock

```bash
docker compose up -d
```

### Step 5: Verify WireMock is Running

```bash
curl http://localhost:8080/__admin/mappings
```

Expected: Returns empty array `{"mappings":[]}` if no stubs loaded, or your stub definitions. If you get connection refused, check that the container is running: `docker compose ps`

### Step 6: Configure HTTP Client

Point your application to `http://localhost:8080` (or `http://wiremock:8080` in Docker network) instead of the real API.

### Step 7: Test Edge Cases

Always test: 200, 400, 401, 403, 404, 429, 500, timeouts, malformed responses.

## Examples

### Example 1: Mock Successful GET Request

```json
{
  "request": { "method": "GET", "url": "/api/users/123" },
  "response": {
    "status": 200,
    "jsonBody": { "id": 123, "name": "Mario Rossi" }
  }
}
```

### Example 2: Mock Server Error

```json
{
  "request": { "method": "GET", "url": "/api/error" },
  "response": { "status": 500, "body": "Internal Server Error" }
}
```

### Example 3: Mock Timeout

```json
{
  "request": { "method": "GET", "url": "/api/slow" },
  "response": {
    "status": 200,
    "fixedDelayMilliseconds": 5000,
    "jsonBody": { "message": "delayed" }
  }
}
```

### Example 4: Docker Compose with Application

```yaml
services:
  wiremock:
    image: wiremock/wiremock:3.5.2
    ports:
      - "8080:8080"
    volumes:
      - ./wiremock:/home/wiremock

  app:
    build: .
    environment:
      - API_BASE_URL=http://wiremock:8080
    depends_on:
      - wiremock
```

## Best Practices

1. **Organize mappings by feature**: Use subdirectories like `users/`, `products/`
2. **Version control mappings**: Keep mappings in git for reproducible tests
3. **Test all error scenarios**: 401, 403, 404, 429, 500, timeouts
4. **Reset between test runs**: `curl -X POST http://localhost:8080/__admin/reset`
5. **Use descriptive file names**: `get-user-success.json`, `post-user-error.json`

## Constraints and Warnings

- Ensure port 8080 is available or map to a different port
- Configure Docker networking when running multiple containers
- Enable `--global-response-templating` for dynamic responses
- WireMock resets mappings on container restart

## Troubleshooting

**Requests don't match stubs?**
Check what WireMock received: `curl http://localhost:8080/__admin/requests` — shows unmatched requests with details about what was actually sent.

**Stub file not loading?**
Verify file location: place JSON stubs in `wiremock/mappings/` and response files in `wiremock/__files/`. Check file permissions.

**Connection refused errors?**
Run `docker compose ps` to verify the container is running. Check port conflicts with `lsof -i :8080`.

## References

See `references/` for complete examples:
- `docker-compose.yml` - Full Docker Compose configuration
- `wiremock/mappings/` - Complete stub examples for all scenarios

More from giuseppe-trisciuoglio/developer-kit

SkillDescription
adr-draftingCreates new Architecture Decision Record (ADR) documents for significant architectural changes using a consistent template and repository-aware naming and storage guidance. Use when a user or agent decides on an architectural change, needs to document technical rationale, or wants to add a new ADR to the project history.
aws-cdkProvides AWS CDK TypeScript patterns for defining, validating, and deploying AWS infrastructure as code. Use when creating CDK apps, stacks, and reusable constructs, modeling serverless or VPC-based architectures, applying IAM and encryption defaults, or testing and reviewing `cdk synth`, `cdk diff`, and `cdk deploy` changes. Triggers include "aws cdk typescript", "create cdk app", "cdk stack", "cdk construct", "cdk deploy", and "cdk test".
aws-cli-beastProvides advanced AWS CLI patterns for managing EC2, Lambda, S3, DynamoDB, RDS, VPC, IAM, and CloudWatch. Generates bulk operation scripts, automates cross-service workflows, validates security configurations, and executes JMESPath queries for complex filtering. Triggers on "aws cli help", "aws command line", "aws scripting", "aws automation", "aws batch operations", "aws bulk operations", "aws cli pagination", "aws multi-region", "aws profiles", "aws cli troubleshooting".
aws-cloudformation-auto-scalingProvides AWS CloudFormation patterns for Auto Scaling including EC2, ECS, and Lambda. Use when creating Auto Scaling groups, launch configurations, launch templates, scaling policies, lifecycle hooks, and predictive scaling. Covers template structure with Parameters, Outputs, Mappings, Conditions, cross-stack references, and best practices for high availability and cost optimization.
aws-cloudformation-bedrockProvides AWS CloudFormation patterns for Amazon Bedrock resources including agents, knowledge bases, data sources, guardrails, prompts, flows, and inference profiles. Use when creating Bedrock agents with action groups, implementing RAG with knowledge bases, configuring vector stores, setting up content moderation guardrails, managing prompts, orchestrating workflows with flows, and configuring inference profiles for model optimization.
aws-cloudformation-cloudfrontProvides AWS CloudFormation patterns for CloudFront distributions, origins (ALB, S3, Lambda@Edge, VPC Origins), CacheBehaviors, Functions, SecurityHeaders, parameters, Outputs and cross-stack references. Use when creating CloudFront distributions with CloudFormation, configuring multiple origins, implementing caching strategies, managing custom domains with ACM, configuring WAF, and optimizing performance.
aws-cloudformation-cloudwatchProvides AWS CloudFormation patterns for CloudWatch monitoring, metrics, alarms, dashboards, logs, and observability. Use when creating CloudWatch metrics, alarms, dashboards, log groups, log subscriptions, anomaly detection, synthesized canaries, Application Signals, and implementing template structure with Parameters, Outputs, Mappings, Conditions, cross-stack references, and CloudWatch best practices for monitoring production infrastructure.
aws-cloudformation-dynamodbProvides AWS CloudFormation patterns for DynamoDB tables, GSIs, LSIs, auto-scaling, and streams. Use when creating DynamoDB tables with CloudFormation, configuring primary keys, local/global secondary indexes, capacity modes (on-demand/provisioned), point-in-time recovery, encryption, TTL, and implementing template structure with Parameters, Outputs, Mappings, Conditions, cross-stack references.
aws-cloudformation-ec2Provides AWS CloudFormation patterns for EC2 instances, Security Groups, IAM roles, and load balancers. Use when creating EC2 instances, SPOT instances, Security Groups, IAM roles for EC2, Application Load Balancers (ALB), Target Groups, and implementing template structure with Parameters, Outputs, Mappings, Conditions, and cross-stack references.
aws-cloudformation-ecsProvides AWS CloudFormation patterns for ECS clusters, task definitions, services, container definitions, auto scaling, blue/green deployments, CodeDeploy integration, ALB integration, service discovery, monitoring, logging, template structure, parameters, outputs, and cross-stack references. Use when creating ECS clusters with CloudFormation, configuring Fargate and EC2 launch types, implementing blue/green deployments, managing auto scaling, integrating with ALB and NLB, and implementing ECS best practices.