Files
euchre_camp/e2e/cucumber
david 9353ab1edc
Pull Request / unit-tests (pull_request) Successful in 57s
Pull Request / e2e-tests (pull_request) Failing after 1m49s
Pull Request / analyze-bump-type (pull_request) Has been skipped
wip: Tournament schedule tests - 27/30 passing
Progress on issue #7 - tournament schedule e2e tests:
- Created ScheduleDisplay component with clickthrough to matches
- Updated ScheduleGenerator to use router.refresh() instead of window.location.reload()
- Fixed step definitions to handle page hydration and reloads
- Fixed database cleanup hook to use Prisma API instead of raw SQL
- Added test IDs and logging for debugging
- Updated feature file to match actual UI behavior

27/30 scenarios passing:
- All auth and navigation scenarios pass
- Scenario 1 (view schedule page) passes
- Scenarios 2-4 (generate schedule, view rounds, click matchup) need investigation

Remaining issues:
1. Page refresh not picking up newly generated schedule data
2. Round data not visible after 'Generated' message
3. Matchup elements not found after refresh
4. Database cleanup hook needs proper handling of foreign keys

Next steps:
1. Investigate why router.refresh() and explicit reload don't show new data
2. Check if there's a caching issue in the production build
3. Verify database transactions are committing correctly
4. Add more logging to trace data flow
2026-04-27 00:29:38 -07:00
..

Cucumber Gherkin-Style E2E Tests

This directory contains Gherkin-style acceptance tests using Cucumber and Playwright for testing the EuchreCamp application.

Overview

These tests follow the Given-When-Then syntax for behavior-driven development (BDD) and test the application from a user's perspective by interacting with the browser UI only.

Key Principles

  1. Browser-only interactions: Tests interact with the application via the browser (click, type, navigate)
  2. No direct database access: All data is created/modified through the UI
  3. Dev site testing: Tests run against a running development server
  4. Happy path focus: Tests verify common user workflows
  5. Gherkin syntax: Tests are written in plain English using Given-When-Then

Running Tests

Run all Cucumber tests

bun run test:acceptance:cucumber

Run with pretty formatter (visible output)

bun run test:acceptance:cucumber:pretty

Run specific feature file

bun cucumber-js e2e/cucumber/features/user-registration.feature

Run specific scenario

bun cucumber-js --name "Successful registration with valid data"

Dry run (check for undefined steps)

bun cucumber-js --config e2e/cucumber/cucumber.config.ts --dry-run

Test Structure

e2e/cucumber/
├── features/           # Gherkin feature files (6 files, 16 scenarios)
│   ├── authentication.feature          # Login/logout flows
│   ├── password-reset.feature          # Password reset (issue #10)
│   ├── player-schedule.feature         # Player schedule view (issue #9)
│   ├── tournament-schedule.feature     # Tournament schedule tab (issue #7)
│   ├── user-registration.feature       # User registration flows
│   └── wordmark-navigation.feature     # Wordmark navigation (issue #24)
├── step-definitions/   # Step implementations (75 steps defined)
│   ├── common-steps.ts    # Navigation, forms, assertions
│   └── auth-steps.ts      # Login, logout, registration, schedule
├── support/            # Test infrastructure
│   ├── world.ts       # Shared test context
│   └── hooks.ts       # Before/After hooks
├── cucumber.config.ts # Cucumber configuration
└── README.md          # This file

Feature Files

1. user-registration.feature

User registration scenarios with validation

2. authentication.feature

Login/logout flows for authenticated users

3. wordmark-navigation.feature

Tests for Issue #24: Wordmark navigation based on user role

4. password-reset.feature

Tests for Issue #10: Password reset flow (marked @wip - needs implementation)

5. player-schedule.feature

Tests for Issue #9: Player schedule view with upcoming matches

6. tournament-schedule.feature

Tests for Issue #7: Tournament admin schedule tab and round-robin generation

Example Test

Feature File (user-registration.feature)

Feature: User Registration
  As a new user
  I want to register for an account
  So that I can participate in Euchre tournaments

  Background:
    Given I am on the registration page

  Scenario: Successful registration with valid data
    When I fill in "name" with "Test User"
    And I fill in "email" with "test@example.com"
    And I fill in "password" with "TestPassword1234!"
    And I click the "Create Account" button
    Then I should be redirected to my profile page
    And my user account should exist

Step Definition (auth-steps.ts)

Given('I am logged in as a player', async function () {
  const credentials = generateTestCredentials();
  world.user = credentials;
  
  await world.page.goto(`${world.baseURL}/auth/register`);
  await world.page.fill('input[name="name"]', credentials.name);
  await world.page.fill('input[name="email"]', credentials.email);
  await world.page.fill('input[name="password"]', credentials.password);
  await world.page.click('button[type="submit"]');
  await world.page.waitForURL(/\/players\/\d+\/profile/);
});

Tags

Use tags to organize and filter tests:

  • @happy-path - Tests successful user workflows
  • @negative-test - Tests error cases and validation
  • @authentication - Tests related to login/registration
  • @wip - Work in progress (skipped by default)
  • @skip - Temporarily skipped tests

Configuration

The Cucumber configuration is in cucumber.config.ts:

  • Feature files: e2e/cucumber/features/**/*.feature
  • Step definitions: e2e/cucumber/step-definitions/**/*.ts
  • TypeScript loader: tsx (for path alias support)
  • Tags: Skips @wip and @skip by default
  • Retries: 2 retries in CI environment

World Context

The world.ts file provides a shared context for tests:

interface WorldState {
  page: Page;           // Playwright page
  context: BrowserContext;
  baseURL: string;      // Dev server URL
  user?: {              // Current test user
    email: string;
    name: string;
    password: string;
  };
  tournament?: any;     // Current test tournament
  player?: any;         // Current test player
}

Hooks

Hooks run before/after tests:

  • BeforeAll - Launch browser once before all tests
  • AfterAll - Close browser and cleanup after all tests
  • Before - Create new page context before each scenario
  • After - Close page and cleanup test data after each scenario

Best Practices

  1. Unique test data: Use timestamps to ensure unique test users
  2. Wait for navigation: Always wait for page loads and redirects
  3. Clear assertions: Verify expected state after user actions
  4. No database access: Use UI/API for all data creation
  5. Tag organization: Use tags to filter test suites
  6. One assertion per step: Keep steps focused and readable

Troubleshooting

Steps showing as undefined

Run with --dry-run to check step matching:

bun cucumber-js --dry-run

Database errors

These tests don't interact with the database directly. If you see Prisma errors, check that:

  • The dev server is running
  • The database is accessible
  • Environment variables are set correctly

Slow tests

Use the @wip tag for tests in development and skip them during full runs.

CI/CD Integration

In CI, the tests should:

  1. Start the dev server (if not already running)
  2. Run Cucumber tests against http://localhost:3000
  3. Use JUnit format for reporting:
    bun cucumber-js --format junit --out reports/cucumber.xml