
Testing
- 56 installs
- 1.1k repo stars
- Updated August 4, 2026
- cloudflare/sandbox-sdk
testing is an agent skill that documents Cloudflare Sandbox SDK unit and E2E test locations, commands, and suite selection conventions.
About
The testing skill documents project-specific test conventions for the Cloudflare Sandbox SDK monorepo. It splits work between unit tests for isolated client logic, service methods, and utilities versus E2E tests for full request flows, real Docker containers, and process lifecycle behavior. Unit tests live in packages/sandbox/tests and packages/sandbox-container/tests, running in Workers via vitest-pool-workers or Bun respectively, with mock containers and createNoOpLogger helpers. E2E tests in tests/e2e exercise real Workers plus Docker, share one container for performance, and isolate cases with unique sessions via createTestSession. Commands cover npm test, workspace-scoped runs, test:e2e, test:e2e:vitest with file filters, and Playwright browser tests. A decision table maps scenarios like command execution, filesystem operations, port exposure, and git workflows to the right suite. Development workflow recommends npm run check, unit tests after changes, and E2E when touching core functionality. Use when writing or running Sandbox SDK tests and choosing between unit and E2E coverage.
- Separates unit tests in packages from E2E tests in tests/e2e.
- Documents npm test, workspace filters, and test:e2e:vitest argument passthrough.
- Maps scenarios like process lifecycle and git operations to E2E coverage.
- E2E suite shares one container with per-test session isolation.
- Recommends npm run check then unit tests after meaningful code changes.
Testing by the numbers
- 56 all-time installs (skills.sh)
- Ranked #1,182 of 2,153 Testing & QA skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
testing capabilities & compatibility
- Capabilities
- unit versus e2e suite selection · workspace test command reference · mock container and logger patterns · e2e session isolation with createtestsession · development check and test workflow
- Works with
- docker
- Use cases
- testing
What testing says it does
This skill covers project-specific testing conventions.
All tests share ONE container for performance
npx skills add https://github.com/cloudflare/sandbox-sdk --skill testingAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 56 |
|---|---|
| repo stars | ★ 1.1k |
| Last updated | August 4, 2026 |
| Repository | cloudflare/sandbox-sdk ↗ |
Should I write a unit or E2E test for Sandbox SDK changes and how do I run the right suite?
Choose unit versus E2E tests, run Sandbox SDK test suites, and follow mock and isolation conventions for Workers and Docker.
Who is it for?
Contributors writing or running Sandbox SDK tests who need unit versus E2E guidance.
Skip if: Skip for TDD methodology itself; use superpowers:test-driven-development for that workflow.
When should I use this skill?
User writes or runs Sandbox SDK tests or asks which suite covers a scenario.
What you get
Correct test type chosen with passing unit or E2E runs following project mock and session patterns.
Files
Testing in Sandbox SDK
This skill covers project-specific testing conventions. For TDD methodology, use the superpowers:test-driven-development skill.
Two Test Suites
Unit Tests
When to use: Testing isolated logic, client behavior, service methods, utilities.
Location:
- SDK:
packages/sandbox/tests/ - Container:
packages/sandbox-container/tests/
Runtime:
- SDK tests run in Workers runtime via
@cloudflare/vitest-pool-workers - Container tests run in Bun runtime
Commands:
npm test # All unit tests
npm test -w @cloudflare/sandbox # SDK tests only
npm test -w @repo/sandbox-container # Container tests onlyMock patterns:
- SDK tests use a mock container (no Docker needed)
- Container tests mock external dependencies (filesystem, processes)
- Use
createNoOpLogger()from@repo/sharedfor logger mocks
Known issue: SDK unit tests may hang on exit due to vitest-pool-workers workerd shutdown. Tests still pass/fail correctly - the hang is cosmetic.
E2E Tests
When to use: Testing full request flow, container integration, real Docker behavior.
Location: tests/e2e/
Runtime: Real Cloudflare Workers + Docker containers
Commands:
npm run test:e2e # All E2E tests (vitest + browser)
npm run test:e2e:vitest -- -- tests/e2e/process-lifecycle-workflow.test.ts # Single vitest file
npm run test:e2e:vitest -- -- tests/e2e/git-clone-workflow.test.ts -t 'test name' # Single vitest test
npm run test:e2e:browser # Browser tests only (Playwright)Note: Use test:e2e:vitest when filtering tests. The test:e2e wrapper doesn't support argument passthrough.
Key patterns:
- All tests share ONE container for performance
- Use unique sessions for test isolation
- Tests run in parallel via thread pool
- Config:
vitest.e2e.config.ts(root level)
Writing E2E tests:
import { createTestSession } from './helpers';
describe('Feature X', () => {
let session: TestSession;
beforeEach(async () => {
session = await createTestSession(); // Gets unique session
});
it('should do something', async () => {
const result = await session.sandbox.exec('echo hello');
expect(result.stdout).toBe('hello\n');
});
});When to Use Which
| Scenario | Test Type |
|---|---|
| Client method logic | Unit |
| Service business logic | Unit |
| Request/response handling | Unit |
| Full command execution flow | E2E |
| File operations with real filesystem | E2E |
| Process lifecycle (start, stop, signal) | E2E |
| Port exposure and preview URLs | E2E |
| Git operations | E2E |
Test-Specific Conventions
File naming: *.test.ts for both unit and E2E tests
Test structure:
describe('ComponentName', () => {
describe('methodName', () => {
it('should do X when Y', async () => {
// Arrange
// Act
// Assert
});
});
});Assertions: Use vitest's expect() with clear, specific assertions
Running Tests During Development
After making any meaningful code change:
1. npm run check - catch type errors first 2. npm test - verify unit tests pass 3. npm run test:e2e - if touching core functionality
Build trust: The monorepo build system handles dependencies automatically. E2E tests always run against latest built code - no manual rebuild needed.
Related skills
FAQ
What does the Sandbox SDK testing skill cover?
Unit versus E2E decisions, file locations, npm commands, mock patterns, and E2E session isolation.
When should I run E2E instead of unit tests?
For full command execution, real filesystem, process lifecycle, port exposure, or git operation flows.
Is the Sandbox SDK testing skill safe to install?
Review the Security Audits panel on this page before installing in production.