Skip to content
Back to skills

Sqs Tests

ASecurity

Tests AWS SQS queue interactions - Standard (at-least-once delivery, near-unlimited throughput) vs FIFO (exactly-once processing, ordered) queue semantics; visibility-timeout interaction model; dead-letter queue (DLQ) for poison-message isolation; message retention period (default 4 days, configurable 60s - 1209600s); test patterns via LocalStack or `aws-sdk-client-mock` (TypeScript) / `moto` (Python). Use when the user works with AWS SQS producers/consumers and needs unit/integration tests f...

  • 10 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added October 12, 2026
testingtypescriptpythondockerawsterraformtestingapi

Works with

  • cli
  • api

Security analysis

A100/100

Pro scans all 3 files and shows the line behind each finding

Scanned October 12, 2026

npx -y skills add testland/qa --skill sqs-tests --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Sqs Tests?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Sqs Tests
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/testland-sqs-tests/badge)](https://www.skillsdirectory.com/skills/testland-sqs-tests)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: sqs-tests
description: "Tests AWS SQS queue interactions - Standard (at-least-once delivery, near-unlimited throughput) vs FIFO (exactly-once processing, ordered) queue semantics; visibility-timeout interaction model; dead-letter queue (DLQ) for poison-message isolation; message retention period (default 4 days, configurable 60s - 1209600s); test patterns via LocalStack or `aws-sdk-client-mock` (TypeScript) / `moto` (Python). Use when the user works with AWS SQS producers/consumers and needs unit/integration tests for queue interactions."
---

# sqs-tests

## Overview

[sqs-dg]: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html

Two queue types, per [the SQS developer guide][sqs-dg]:

| Type | Delivery semantics |
|---|---|
| **Standard** | "at-least-once message delivery" |
| **FIFO** | "exactly-once message processing" + "high-throughput" mode |

The semantic difference cascades through every test pattern: a
Standard-queue test must assume duplicates can occur; a FIFO test
must assume strict ordering.

## When to use

- The repo has SQS-publishing or SQS-consuming code (AWS SDK).
- The user writes unit tests against mocked SQS clients.
- The user writes integration tests against LocalStack / real SQS
  (in a sandbox account).
- A test verifies visibility-timeout, DLQ-routing, or
  long-polling behavior.

## Step 1 - Test approach: mock vs LocalStack vs real

Three approaches, ordered by isolation:

| Approach | Pros | Cons |
|---|---|---|
| `aws-sdk-client-mock` (TS) / `moto` (Python) | Pure unit, no network | Doesn't catch AWS-side behavior (visibility timeouts, DLQ routing) |
| LocalStack (Docker SQS emulator) | Full SQS semantics locally | Slower; not 100% behavior parity with AWS SQS |
| Real SQS in sandbox AWS account | Highest fidelity | Costs money; per-PR queue cleanup needed |

For pure logic tests (does the code call SendMessage with the right
body?), use mocks. For semantic tests (does retry-on-failure work
end-to-end?), use LocalStack. For pre-prod smoke, use real SQS.

## Step 2 - Mock-based unit test (TypeScript)

```typescript
import { mockClient } from 'aws-sdk-client-mock';
import { SQSClient, SendMessageCommand } from '@aws-sdk/client-sqs';

const sqsMock = mockClient(SQSClient);
beforeEach(() => sqsMock.reset());

it('sends order-placed message to SQS', async () => {
  sqsMock.on(SendMessageCommand).resolves({ MessageId: 'msg-123' });

  await placeOrder({ customerId: 1 });

  expect(sqsMock.commandCalls(SendMessageCommand)).toHaveLength(1);
  expect(sqsMock.commandCalls(SendMessageCommand)[0].args[0].input).toMatchObject({
    QueueUrl: expect.stringContaining('orders'),
    MessageBody: expect.stringContaining('"customerId":1'),
  });
});
```

## Step 3 - Mock-based unit test (Python)

```python
import boto3
from moto import mock_aws

@mock_aws
def test_send_order_message():
    sqs = boto3.client('sqs', region_name='us-east-1')
    queue_url = sqs.create_queue(QueueName='orders')['QueueUrl']

    place_order(customer_id=1)

    response = sqs.receive_message(QueueUrl=queue_url, MaxNumberOfMessages=10)
    assert len(response['Messages']) == 1
    body = json.loads(response['Messages'][0]['Body'])
    assert body['customerId'] == 1
```

`moto`'s `@mock_aws` decorator intercepts boto3 SQS calls; tests run
without network.

## Step 4 - LocalStack integration test

```yaml
# docker-compose.yml
services:
  localstack:
    image: localstack/localstack:latest
    ports: [4566:4566]
    environment:
      SERVICES: sqs
```

```python
sqs = boto3.client(
    'sqs',
    endpoint_url='http://localhost:4566',
    region_name='us-east-1',
    aws_access_key_id='test', aws_secret_access_key='test',
)
queue_url = sqs.create_queue(QueueName='orders')['QueueUrl']
# ... full SQS API works, including visibility timeouts, DLQ, FIFO
```

## Step 5 - Test visibility-timeout behavior

Visibility timeout keeps an in-flight message invisible to other
receivers for a configurable window, preventing duplicate processing
([SQS developer guide][sqs-dg]).

Test pattern (LocalStack or real SQS, NOT mock):

```python
sqs.send_message(QueueUrl=queue_url, MessageBody='test')
msg1 = sqs.receive_message(QueueUrl=queue_url, VisibilityTimeout=30)['Messages'][0]
# Within 30s, the message should be invisible to other receivers:
msg2 = sqs.receive_message(QueueUrl=queue_url)
assert msg2.get('Messages') is None
# After visibility timeout (or explicit ChangeMessageVisibility), it returns:
sqs.change_message_visibility(
    QueueUrl=queue_url,
    ReceiptHandle=msg1['ReceiptHandle'],
    VisibilityTimeout=0,
)
msg3 = sqs.receive_message(QueueUrl=queue_url)
assert msg3['Messages'][0]['MessageId'] == msg1['MessageId']
```

## Step 6 - Test DLQ routing

SQS routes a message to the dead-letter queue after `maxReceiveCount`
failed deliveries (poison-message isolation, per the SQS developer
guide). Full LocalStack recipe:
[references/localstack-recipes.md](references/localstack-recipes.md).

## Step 7 - Test FIFO ordering + dedup

FIFO queues (`FifoQueue: 'true'`) preserve per-`MessageGroupId` order
and drop identical bodies within a 5-minute dedup window
(`ContentBasedDeduplication`). Full LocalStack recipe:
[references/localstack-recipes.md](references/localstack-recipes.md).

## Step 8 - Message retention

SQS auto-deletes messages older than the retention period: default 4
days, configurable from 60 seconds to 1,209,600 seconds (14 days)
([SQS developer guide][sqs-dg]). Tests rarely verify retention
directly; document the expected retention in queue setup (Terraform /
CloudFormation) and review per-team.

## Step 9 - CI integration

```yaml
services:
  localstack:
    image: localstack/localstack:latest
    ports: [4566:4566]
    env: { SERVICES: sqs }

steps:
  - run: pytest tests/integration/sqs/ -v
```

## Anti-patterns

| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Test visibility-timeout via mock | Mock doesn't track invisibility window; tests pass-by-accident | Use LocalStack (Step 4 - 5) |
| Skip DLQ-routing test | Poison-message handling unverified; production incidents | Always cover DLQ for production queues (Step 6) |
| Use Standard-queue body assertions sensitive to delivery order | At-least-once = duplicates + reordering | Assert per-message processing idempotency, not order |
| Hard-code queue URLs in tests | Tests break when account / region changes | Pull from env vars / fixtures |

## Limitations

- LocalStack ≠ real SQS - some behaviors (extreme latency, AWS
  throttling) are not emulated.
- FIFO throughput limits (300 messages/sec without
  high-throughput mode) need real SQS to verify.
- Cost-effective sandbox testing requires per-PR queue cleanup; use
  random queue-name suffixes + cleanup hooks.

## References

- [sqs-dg][sqs-dg] - official SQS developer guide; standard vs FIFO,
  visibility timeout, DLQ, retention
- docs.aws.amazon.com/AWSSimpleQueueService - full SQS docs
- localstack.cloud - LocalStack SQS emulator
- pypi.org/project/moto - Python AWS mock
- npmjs.com/package/aws-sdk-client-mock - TypeScript AWS mock
- `sidekiq-tests`,
  `celery-tests`,
  `bullmq-tests`,
  `rabbitmq-tests` - sister tools
- `idempotency-test-author` - 
  critical companion for at-least-once SQS Standard queues

Files in this skill

  • .tessl-plugin/plugin.json644 B
  • SKILL.md7.1 KB
  • references/localstack-recipes.md1.9 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.