fp-update

Update existing E2E tests to match current E2E_TESTS.md specifications

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "fp-update" with this command: npx skills add endorhq/flightplanner/endorhq-flightplanner-fp-update

Update E2E Tests

Update existing E2E tests to match the current state of E2E_TESTS.md specifications. This is the primary maintenance command — use it after specs change to bring tests in sync.

Additional instructions from the user: "$ARGUMENTS". Ignore if empty.

This command has four phases. Complete all four in order.

Phase 1: Discover

  1. Find all E2E_TESTS.md files by searching recursively from the project root. Read the root-level spec first to understand project-wide testing constraints.
  2. If E2E tests already exist, run them first to establish a baseline of current pass/fail status. Note any pre-existing failures.
  3. For each E2E_TESTS.md, extract:
    • All suites
    • For each suite: preconditions, features, postconditions, metadata
  4. Find all existing E2E test files:
    • Files matching **/*.e2e.test.*
    • Files inside **/e2e/**/*.test.*
  5. Read all existing test files to understand current coverage, patterns, and utilities.

Phase 2: Analyze

Map each spec element to existing tests. Build a coverage matrix and identify:

  • Missing suites: Spec suites with no corresponding test file
  • Missing features: Features within a suite with no corresponding test case
  • Missing preconditions/postconditions: Setup or teardown described but not implemented
  • Inconsistencies: Tests that don't match the current spec (wrong assertions, outdated behavior)
  • Structural issues: Tests that violate isolation rules (shared state, ordering dependencies)

Present a summary:

  • Total suites and features in spec
  • Current coverage count
  • List of gaps grouped by suite
  • Any inconsistencies or structural issues

Ask the user if they want to proceed with all updates, or focus on specific suites/features.

Phase 3: Update

Apply changes following these rules:

General rules

  • Follow existing patterns: Study existing E2E test files for code style, utilities, mock strategies, and structure. New/updated tests must be consistent.
  • Test isolation: Every suite starts from a clean slate. No shared persistent state. Tests are order-independent.
  • Mock only external dependencies: Mock CLI tools and external services. Use real file systems, real git repos.
  • Use real test environments: Temporary directories, real git repositories, actual project files.
  • File naming: Follow the existing <feature>.e2e.test.<ext> convention.

For missing suites

  • Create new test files following existing patterns.
  • Implement all features, preconditions, and postconditions.
  • Reuse existing helpers and utilities.

For missing features

  • Add new suite/group blocks and test cases in the appropriate existing test file (e.g., describe / it blocks in vitest/jest).
  • Follow adjacent test case patterns.

For inconsistencies

  • Update test assertions, setup, or structure to match the spec.
  • The spec is the source of truth. Never change the spec to match tests.

For structural issues

  • Refactor to eliminate ordering dependencies and shared state.
  • Ensure proper per-test setup and teardown hooks (e.g., beforeEach / afterEach in vitest/jest).

Phase 4: Verify

  1. Run E2E tests for each updated package.
  2. If tests fail:
    • Read the failure output
    • Fix the test implementation (not the spec)
    • Re-run until passing
  3. Once package-level tests pass, run the full project E2E suite to ensure no cross-package regressions.
  4. Run the project's formatter on all modified files.
  5. Present a final summary:
    • Suites and features added or updated
    • New test files created
    • Existing test files modified
    • Confirmation that all tests pass

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

fp-update-spec

No summary provided by upstream source.

Repository SourceNeeds Review
General

fp-add

No summary provided by upstream source.

Repository SourceNeeds Review
General

fp-generate

No summary provided by upstream source.

Repository SourceNeeds Review
General

fp-fix

No summary provided by upstream source.

Repository SourceNeeds Review