E2E Testing Conventions

Naming conventions and standards for E2E tests in the CONA platform

E2E Testing Conventions

This document outlines the standards and conventions used for automated end-to-end (E2E) testing across the CONA platform, including test identification, organization, and implementation patterns with Playwright.

Automation Framework

All E2E tests are implemented using Playwright, which provides:

• Cross-browser testing (Chromium, Firefox, WebKit)
• Reliable selectors and auto-waiting mechanisms
• Network request interception and mocking
• Parallel test execution
• Visual comparison capabilities

The test structure follows Playwright best practices with page objects, fixtures, and utility functions.

Test Implementation Structure

tests/
├── e2e/
│   ├── fixtures/       # Test fixtures and shared setup
│   ├── helpers/        # Helper functions and utilities
│   ├── pages/          # Page object models
│   ├── shopify/        # Shopify-specific tests
│   │   ├── core/       # Core business logic tests
│   │   ├── integration/# Integration tests
│   │   └── ...         # Other test categories
│   └── datev/          # DATEV-specific tests
└── fixtures/           # Global test fixtures

Test Identification System

To effectively manage and track our extensive test suite, we use a standardized ID system across all test categories:

Test ID Format

• Basic Format: {Module}-{Category}-{Number}
• Example: SH-CORE-001
• File naming: {testId}.spec.ts (e.g., SH-CORE-001.spec.ts)

Module Prefixes

• SH: Shopify integration tests
• DT: DATEV integration tests
• PP: PayPal integration tests
• CORE: Core platform tests
• API: API-specific tests

Category Types

• CORE: Core business logic tests
• INT: Integration tests between systems
• ERR: Error handling and boundary case tests
• PERF: Performance and load tests
• E2E: End-to-end user journey tests
• SEC: Security-focused tests

Numbering Convention

• Three-digit sequential numbering (e.g., 001, 002, 003)
• Numbers are assigned within each module-category combination
• Gaps in numbering are allowed for future insertions

Benefits of Test ID System

• Traceability: Clear mapping between requirements and test cases
• Reporting: Structured test reporting and result analysis
• Communication: Common reference points when discussing test results
• Organization: Logical grouping of related test scenarios
• Maintenance: Easier identification of test coverage gaps

Test Documentation Standards

Each test should be documented with:

1. ID: Unique test identifier
2. Title: Brief, descriptive title
3. Scenario: Concise description of what’s being tested
4. Preconditions: Required system state before test execution
5. Automation Verifications: What the automated test verifies
6. Expected Results: Clear description of expected outcomes
7. Test Data Requirements: Any specific test data needed

Example Test Documentation

### Payment Reconciliation Flow [SH-CORE-002]

**Scenario**: Reconciling payments for completed orders

**Preconditions**:
- Shopify store configured with Shopify Payments
- Multiple completed orders with payments

**What the automation verifies**:
1. Creation of multiple orders with Shopify Payments
2. Payment settlement processing in Shopify
3. Reconciliation process in CONA
4. Updated DATEV export generation
5. Payment reconciliation status

**Expected Result**: 
- Updated DATEV export shows reconciled payments
- Proper accounting entries present in export
- Payment status updated in system

**Test Data Requirements**:
- Test products with various price points
- Valid payment methods configured

Playwright Implementation Guidelines

• Page Objects: Implement page object pattern for all UI interactions
• API Helpers: Create reusable API helpers for backend interactions
• Fixtures: Use Playwright fixtures for setup/teardown and shared context
• Selectors: Prefer data-testid attributes for element selection
• Assertions: Use explicit assertions for all verification points
• Timeouts: Configure appropriate timeouts for async operations
• Retries: Implement retry mechanisms for flaky network operations

Example Test Implementation

// SH-CORE-001.spec.ts
import { test, expect } from '@playwright/test';
import { ShopifyPage } from '../pages/shopify.page';
import { DATEVExportPage } from '../pages/datev-export.page';
import { createTestProduct } from '../helpers/product-helpers';

test.describe('Basic Order with VAT Processing [SH-CORE-001]', () => {
  test.beforeEach(async ({ page }) => {
    // Test setup code
  });

  test('should process order with 19% VAT and create correct DATEV export', async ({ page }) => {
    // Create product with 19% VAT
    const productId = await createTestProduct(page, { vatRate: 19 });
    
    // Complete purchase
    const shopify = new ShopifyPage(page);
    await shopify.purchaseProductWithShopifyPayments(productId);
    
    // Verify order in CONA
    // Generate DATEV export
    const datevExport = new DATEVExportPage(page);
    const exportData = await datevExport.generateExport();
    
    // Verify export content
    expect(exportData.revenueEntries).toContainEqual(
      expect.objectContaining({ 
        vatRate: 19,
        isReconciled: false 
      })
    );
  });
});

Test Data Management

• Use dedicated test data that doesn’t affect production
• Create specific seed data for each test category
• Document data dependencies between tests
• Use data factories to generate test data programmatically
• Reset test data between test runs

CI/CD Integration

• All tests are executed in CI/CD pipelines on pull requests
• Tests are categorized by execution time (fast, medium, slow)
• Critical path tests run on every PR, full suite runs nightly
• Test results are published to test reporting dashboard
• Visual test reports are generated for failures with screenshots

Test Environments

• Development: Local development environment for test writing
• Integration: Shared test environment for basic validation
• Staging: Production-like environment for full test suite
• Production: Subset of non-destructive tests for monitoring