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
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
- Browser-only interactions: Tests interact with the application via the browser (click, type, navigate)
- No direct database access: All data is created/modified through the UI
- Dev site testing: Tests run against a running development server
- Happy path focus: Tests verify common user workflows
- 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
@wipand@skipby 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 testsAfterAll- Close browser and cleanup after all testsBefore- Create new page context before each scenarioAfter- Close page and cleanup test data after each scenario
Best Practices
- Unique test data: Use timestamps to ensure unique test users
- Wait for navigation: Always wait for page loads and redirects
- Clear assertions: Verify expected state after user actions
- No database access: Use UI/API for all data creation
- Tag organization: Use tags to filter test suites
- 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:
- Start the dev server (if not already running)
- Run Cucumber tests against
http://localhost:3000 - Use JUnit format for reporting:
bun cucumber-js --format junit --out reports/cucumber.xml