> ## Documentation Index
> Fetch the complete documentation index at: https://cona.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

```markdown theme={null}
### 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

```typescript theme={null}
// 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