73 lines
3.4 KiB
Markdown
73 lines
3.4 KiB
Markdown
# quality-gates Specification
|
|
|
|
## Purpose
|
|
Define Composer quality scripts, architecture boundaries, PostgreSQL-backed feature tests, and the five blocking CI jobs including browser functional, accessibility and motion coverage.
|
|
|
|
## Requirements
|
|
### Requirement: Standardized Composer test scripts exist
|
|
|
|
The system SHALL expose Composer scripts equivalent to `test:unit`, `test:feature`, `test:browser`, `test`, and `quality` with the composition defined in SPEC §13.9.
|
|
|
|
#### Scenario: Developer runs full quality gate locally
|
|
|
|
- **WHEN** a developer runs `composer quality`
|
|
- **THEN** the command executes static analysis, audits, and the applicable test suites
|
|
|
|
### Requirement: Architecture tests enforce domain boundaries
|
|
|
|
The system SHALL include Pest architecture tests that verify `App\Domain` uses strict types and does not depend on `App\Filament` or `App\Livewire`.
|
|
|
|
#### Scenario: Domain layer violates boundary
|
|
|
|
- **WHEN** code in `App\Domain` imports from `App\Filament` or `App\Livewire`
|
|
- **THEN** the architecture test suite MUST fail
|
|
|
|
### Requirement: CI pipeline blocks merge on five jobs
|
|
|
|
The system SHALL run a CI pipeline with blocking jobs named `static`, `unit`, `feature`, `browser`, and `container` as defined in SPEC §14.1.
|
|
|
|
#### Scenario: Static analysis fails on pull request
|
|
|
|
- **WHEN** a pull request introduces a Pint, PHPStan/Larastan, or Composer audit failure
|
|
- **THEN** the `static` job MUST fail and block merge
|
|
|
|
#### Scenario: Feature tests use PostgreSQL
|
|
|
|
- **WHEN** the `feature` CI job runs integration tests
|
|
- **THEN** the job MUST use PostgreSQL and MUST NOT substitute SQLite
|
|
|
|
### Requirement: Local feature tests use PostgreSQL
|
|
|
|
The system SHALL configure `phpunit.xml` so that the Feature test suite uses PostgreSQL with the same connection parameters as CI (`DB_CONNECTION=pgsql`, host, port, database `amare_test`, credentials). Local feature tests MUST NOT default to SQLite `:memory:`.
|
|
|
|
#### Scenario: Developer runs feature tests locally
|
|
|
|
- **WHEN** a developer runs `composer test:feature` with PostgreSQL available
|
|
- **THEN** tests MUST execute against PostgreSQL
|
|
- **AND** MUST NOT silently fall back to SQLite
|
|
|
|
#### Scenario: Feature tests exercise PostgreSQL-specific types
|
|
|
|
- **WHEN** feature tests persist records with jsonb columns (e.g., `social_links`)
|
|
- **THEN** migrations and constraints MUST be validated against PostgreSQL semantics
|
|
|
|
### Requirement: Browser tests run against FrankenPHP-served application
|
|
|
|
The system SHALL execute browser tests using Pest Browser/Playwright against an application served by FrankenPHP in CI. The `browser` job MUST cover the E2E journeys available in the current phase, automated accessibility checks, motion behavior and smoke checks for public routes (SPEC §13.4, §13.7 and §14.1), without pixel comparison.
|
|
|
|
#### Scenario: Browser job validates served application
|
|
|
|
- **WHEN** the `browser` CI job runs
|
|
- **THEN** tests execute against the built application artifact or equivalent production-like image
|
|
|
|
#### Scenario: Browser job covers functional, accessibility and motion assertions
|
|
|
|
- **WHEN** the `browser` CI job runs
|
|
- **THEN** it MUST execute the functional browser, accessibility, motion and smoke suites
|
|
- **AND** a failing functional assertion or a critical/serious accessibility issue MUST block merge
|
|
|
|
#### Scenario: Browser failures publish diagnostics
|
|
|
|
- **WHEN** a browser test fails in CI
|
|
- **THEN** the job MUST publish application logs and browser logs as diagnostics
|