Baring Blueprints

Overview

Most portfolio projects demonstrate features. Baring Blueprints demonstrates process. It is a living reference for how I approach modern React development: strict TypeScript, accessibility as a non-negotiable baseline, a complete testing pyramid, and a CI/CD pipeline that runs daily — not just on deployment. It is not a product; it is a standards document written in code.

Key Features

• 68 unit and integration tests — Components, hooks, and utility functions covered with React Testing Library and Vitest
• 26 Playwright E2E tests — Critical user journeys verified in a real browser environment
• Automated accessibility scanning — axe-core integrated into Playwright so accessibility regressions fail the pipeline
• 80%+ coverage thresholds — Enforced hard limit; the build fails if coverage drops below the threshold
• Daily regression pipeline — GitHub Actions runs the full test suite on a nightly cron in addition to push triggers
• shadcn/ui + Framer Motion — Accessible component primitives with motion design system

Architecture

The stack is React 18 + Vite with TanStack Query for async state management. The testing pyramid follows a 70/20/10 ratio: the majority of coverage comes from fast unit and integration tests, with E2E reserved for journeys that require a real browser (navigation, form submission, animations).

# GitHub Actions workflow — daily regression + push trigger
name: CI
on:
  push:
    branches: [main]
  schedule:
    - cron: '0 6 * * *'   # 06:00 UTC daily
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npm run test:coverage
      - run: npx playwright install --with-deps
      - run: npm run test:e2e

axe-core runs inside each Playwright test via @axe-core/playwright, injecting the accessibility engine into the page and asserting zero violations before any functional assertions run.

Technical Challenges

1. Balancing E2E coverage with CI run time

A large E2E suite can make CI slow enough that developers stop running it. The solution was Playwright's built-in worker parallelization: tests are distributed across workers, keeping the full suite under 90 seconds. Test files are organized so unrelated features never share state and can always run in parallel.

2. Making accessibility a pipeline gate, not a manual audit

Accessibility is easy to defer when it is a separate audit step. Integrating axe-core into Playwright means every E2E test also runs an accessibility check. A contrast ratio regression or missing ARIA label breaks the build the same way a broken button does. This removes the "we'll fix it later" escape hatch.

What I Learned

Structuring a repository for long-term maintainability is different from making it work. Clear separation between unit, integration, and E2E tests — with rules about what belongs at each layer — makes the suite fast, trustworthy, and easy to extend. Configuring CI/CD from scratch clarified how much is typically hidden behind platform defaults. And integrating accessibility into the automated pipeline shifted my mental model: accessibility is not a feature to add; it is a regression to prevent.