Files
leo-claude-mktplace/plugins/saas-test-pilot/skills/test-patterns.md
lmiranda 2d51df7a42 feat(marketplace): command consolidation + 8 new plugins (v8.1.0 → v9.0.0) [BREAKING]
Phase 1b: Rename all ~94 commands across 12 plugins to /<noun> <action>
sub-command pattern. Git-flow consolidated from 8→5 commands (commit
variants absorbed into --push/--merge/--sync flags). Dispatch files,
name: frontmatter, and cross-reference updates for all plugins.

Phase 2: Design documents for 8 new plugins in docs/designs/.

Phase 3: Scaffold 8 new plugins — saas-api-platform, saas-db-migrate,
saas-react-platform, saas-test-pilot, data-seed, ops-release-manager,
ops-deploy-pipeline, debug-mcp. Each with plugin.json, commands, agents,
skills, README, and claude-md-integration. Marketplace grows from 12→20.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-06 14:52:11 -05:00

2.3 KiB

description
description
Test design patterns for unit, integration, and e2e tests

Test Patterns Skill

Overview

Standard test design patterns organized by test type. Use these as templates when generating tests.

Unit Test Patterns

Arrange-Act-Assert (AAA)

The default pattern for unit tests:

Arrange: Set up test data and dependencies
Act:     Call the function under test
Assert:  Verify the result matches expectations
  • Keep Arrange minimal — only what this specific test needs
  • Act should be a single function call
  • Assert one logical concept (multiple assertions allowed if same concept)

Parameterized Tests

Use when testing the same logic with different inputs:

  • pytest: @pytest.mark.parametrize("input,expected", [...])
  • Jest: test.each([...])("description %s", (input, expected) => {...})

Best for: validation functions, parsers, formatters, math operations.

Exception Testing

Verify error conditions explicitly:

  • pytest: with pytest.raises(ValueError, match="expected message")
  • Jest: expect(() => fn()).toThrow("expected message")

Always assert the exception type AND message content.

Integration Test Patterns

Setup/Teardown

Use fixtures or beforeEach/afterEach for:

  • Database connections and seeded data
  • Temporary files and directories
  • Mock server instances
  • Environment variable overrides

Transaction Rollback

For database integration tests, wrap each test in a transaction that rolls back:

  • Ensures test isolation without slow re-seeding
  • pytest: @pytest.fixture(autouse=True) with session-scoped DB and function-scoped transaction

E2E Test Patterns

Page Object Model

Encapsulate page interactions in reusable classes:

  • One class per page or significant component
  • Methods return page objects for chaining
  • Selectors defined as class properties
  • No assertions inside page objects

User Flow Pattern

Structure E2E tests as user stories:

  1. Setup — authenticate, navigate to starting point
  2. Action — perform the user's workflow steps
  3. Verification — check the final state
  4. Cleanup — reset any created data

Anti-Patterns to Avoid

  • Testing implementation details instead of behavior
  • Mocking the thing you are testing
  • Tests that depend on execution order
  • Assertions on exact error messages from third-party libraries
  • Sleeping instead of waiting for conditions