DEV Community: Artur DefToExplore

pr-checkmate: Stop Debating Style and Start Coding

Artur DefToExplore — Thu, 20 Nov 2025 14:46:54 +0000

Stop wasting time on code reviews discussing semicolons and spacing. Automate everything with PR CheckMate.

The Problem We All Face

Picture this: It's Monday morning. Your team just opened a pull request. Within minutes, review comments start rolling in:

"Please add a semicolon here"
"Run Prettier on this file"
"Did you check the spelling in the README?"
"ESLint is complaining about unused variables"

Sound familiar? 😅

Developers end up spending time on mechanical tasks instead of solving real problems. The review process slows down. People get frustrated. And the worst part? These issues are completely preventable.

The Real Cost of Manual Code Quality Checks

Consider what happens in a typical day:

Developer writes a feature → pushes code
Reviewer notices formatting issues → requests changes
Developer runs Prettier manually → commits again
Reviewer finds a typo in documentation → another round
Developer fixes it → push again
CI/CD pipeline finally runs ESLint → more failures
Repeat 3-4 times before merge

That's not one PR anymore — that's chaos.

Introducing PR CheckMate

www.npmjs.com/package/pr-checkmate

PR CheckMate is an npm package that bundles all your code quality tools into one zero-config solution:

✅ ESLint — catches code issues and style violations
✅ Prettier — auto-formats your entire codebase
✅ Dependency Checks — alerts you to suspicious package.json changes
✅ cspell — catches spelling mistakes in code and docs
✅ Scans for secrets using
✅ Package Vulnerabilities Check
✅ Auto-commit — fixes issues and commits automatically

No more manual setup. No more forgetting to run formatters. Just install once and let it work.

Installation & Setup (2 minutes)

Step 1: Install PR CheckMate

npm install --save-dev pr-checkmate

That's it. You don't need to install ESLint, Prettier, or cspell separately. PR CheckMate includes them all.

Step 2: Initialize Configuration

npx pr-checkmate init

You'll be prompted to specify your source path:

? Where is your project source code? (Use arrow keys)
❯ src 
  app 
  Enter manually

This creates a pr-checkmate.json file:

{
  "sourcePath": "src"
}

Step 3: (Optional) Customize Configuration

PR CheckMate ships with sensible defaults, but you can customize:

ESLint rules — add your .eslintrc.js or eslint.config.mjs
Prettier config — add your .prettierrc
Spellcheck dictionary — add your cspell.json

If you have local configs, PR CheckMate automatically detects and uses them. Otherwise, it uses bundled defaults.

Running Checks Locally

Before pushing, run checks locally to catch issues early:

# Run all checks
npx pr-checkmate all

# Run specific checks
npx pr-checkmate lint         # ESLint only
npx pr-checkmate prettier     # Format code
npx pr-checkmate deps         # Check dependencies
npx pr-checkmate spellcheck   # Spell check
npx pr-checkmate security.    # Security scan
npx pr-checkmate npm-audit.   # Package vulnerabilities check

Real Example Output

🚀 Running job: all
🔍 Running ESLint...
📋 Using local ESLint config
✅ ESLint passed

📦 Checking dependencies...
✅ Dependencies OK

🎨 Running Prettier...
📋 Using local Prettier config
✅ Prettier completed

🔤 Running spellcheck...
📦 Using pr-checkmate cspell config
✅ Spellcheck passed

Integrating with GitHub Actions

This is where the magic happens. Set up automated checks on every pull request:

Create `.github/workflows/pr-quality.yml`

name: 🔍 PR Quality Checks

on:
  pull_request:
    branches: [main, develop]

jobs:
  quality-checks:
    runs-on: ubuntu-latest

    steps:
      - name: 📥 Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: 🔧 Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: 📦 Install dependencies
        run: npm ci

      - name: 🔍 Run PR CheckMate
        run: npx pr-checkmate all

What this does:

Triggers on every pull request to main or develop
Checks out your code
Sets up Node.js with caching (faster builds!)
Installs dependencies
Runs all PR CheckMate checks

Result

Now every PR is automatically validated. No manual intervention needed:

✅ Lint check passed
✅ Dependency check passed
✅ Prettier formatting verified
✅ Spellcheck passed
✅ Scans for secrets using
✅ Package Vulnerabilities Check

If any check fails, the PR is blocked until issues are fixed. This happens before code review even begins.

Advanced: Auto-fix and Auto-commit

Want PR CheckMate to fix issues automatically? Create a more advanced workflow:

name: 🔧 Auto-fix Code Issues

on:
  pull_request:
    branches: [main]

permissions:
  contents: write
  pull-requests: write

jobs:
  auto-fix:
    runs-on: ubuntu-latest

    steps:
      - name: 📥 Checkout code
        uses: actions/checkout@v4
        with:
          ref: ${{ github.head_ref }}

      - name: 🔧 Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: 📦 Install dependencies
        run: npm ci

      - name: 🔍 Run PR CheckMate
        run: npx pr-checkmate prettier

      - name: 💾 Commit changes
        run: |
          git config user.name "PR CheckMate Bot"
          git config user.email "bot@checkmate.dev"
          git add -A
          if ! git diff --cached --quiet; then
            git commit -m "style: auto-format code with Prettier"
            git push
          fi

This workflow:

Runs Prettier on every PR
Auto-commits formatting fixes
Pushes changes back to the PR

No more back-and-forth on formatting! 🎉

Real-World Example: Before and After

Before PR CheckMate

PR opened → 1st review → "add semicolons" → developer fixes → 2nd review 
→ "run prettier" → developer fixes → 3rd review → "spellcheck readme" 
→ developer fixes → 4th review → finally approved ❌ Takes 2-3 hours

After PR CheckMate

PR opened → Automated checks run → All issues fixed → ✅ Ready to review
→ Code review in 15 minutes → Merged

What Each Tool Does

🔍 ESLint (Linting)

Catches code issues before they cause bugs:

// ❌ ESLint catches these:
var x = 1;        // Should use const/let
if (x == 1) {}    // Should use ===
unused_var = 2;   // Unused variable

🎨 Prettier (Formatting)

Enforces consistent style automatically:

// Before Prettier
const obj={a:1,b:2,c:3}
const fn=(x)=>x*2

// After Prettier
const obj = { a: 1, b: 2, c: 3 };
const fn = x => x * 2;

📦 Dependency Check

Alerts to suspicious package.json changes:

{
  "name": "my-project",
  "version": "1.0.0",
  "dependencies": {
    // Added 50 new packages? ⚠️ Flag for review
    "random-package": "^1.0.0"
  }
}

🔤 cspell (Spellcheck)

Catches typos in code, docs, and JSON:

❌ "Dependancies" → ✅ "Dependencies"
❌ "occured" → ✅ "Occurred"
❌ "seperate" → ✅ "Separate"

Configuration: Customizing Rules

Using Your Own ESLint Config

Just create an eslint.config.mjs in your project root. PR CheckMate will use it:

// eslint.config.mjs
import tsPlugin from '@typescript-eslint/eslint-plugin';
import tsParser from '@typescript-eslint/parser';

export default [
  {
    files: ['**/*.ts', '**/*.tsx'],
    languageOptions: {
      parser: tsParser,
    },
    plugins: {
      '@typescript-eslint': tsPlugin,
    },
    rules: {
      '@typescript-eslint/no-explicit-any': 'error',
      'no-console': 'warn',
    },
  },
];

Custom Prettier Config

Create .prettierrc:

{
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "printWidth": 100,
  "tabWidth": 2
}

Custom Spellcheck Dictionary

Create cspell.json:

{
  "version": "0.2",
  "language": "en",
  "words": [
    "mycompany",
    "TypeScript",
    "ESLint"
  ],
  "ignorePaths": [
    "**/node_modules/**",
    "**/dist/**"
  ]
}

FAQ

Q: Do I need to install ESLint, Prettier, and cspell separately?
A: No! PR CheckMate bundles them all. Just install pr-checkmate and you're done.

Q: What if I already have ESLint configured?
A: PR CheckMate detects your local config and uses it automatically.

Q: Can I use this in monorepos?
A: Yes! Specify different source paths using pr-checkmate.json.

Q: Does it slow down my CI/CD pipeline?
A: No. Most checks complete in seconds. It's faster than manual reviews!

Q: Can I skip certain checks?
A: Yes, disable them in your workflow:

- name: Run only linting
  run: npx pr-checkmate lint

Q: What Node versions are supported?
A: Node 18.0.0 and above.

Getting Started Today

Install: npm install --save-dev pr-checkmate
Initialize: npx pr-checkmate init
Test locally: npx pr-checkmate all
Add to CI: Copy the GitHub Actions workflow above
Push: Enjoy automatic code quality checks! 🎉

The Bottom Line

Code quality shouldn't require manual effort. ESLint, Prettier, and spellchecks should just work automatically, before code review even begins.

PR CheckMate eliminates the friction. Your team can focus on what matters: solving problems, not debating semicolons.

Try it today. Your pull request reviews will never be the same.

Automating Code Quality: Stop Debating Style and Start Coding

Artur DefToExplore — Thu, 20 Nov 2025 11:02:16 +0000

Stop wasting time on code reviews discussing semicolons and spacing. Automate everything with PR CheckMate.

The Problem We All Face

Picture this: It's Monday morning. Your team just opened a pull request. Within minutes, review comments start rolling in:

"Please add a semicolon here"
"Run Prettier on this file"
"Did you check the spelling in the README?"
"ESLint is complaining about unused variables"

Sound familiar? 😅

The Real Cost of Manual Code Quality Checks

Consider what happens in a typical day:

Developer writes a feature → pushes code
Reviewer notices formatting issues → requests changes
Developer runs Prettier manually → commits again
Reviewer finds a typo in documentation → another round
Developer fixes it → push again
CI/CD pipeline finally runs ESLint → more failures
Repeat 3-4 times before merge

That's not one PR anymore — that's chaos.

Introducing PR CheckMate

www.npmjs.com/package/pr-checkmate

PR CheckMate is an npm package that bundles all your code quality tools into one zero-config solution:

✅ ESLint — catches code issues and style violations
✅ Prettier — auto-formats your entire codebase
✅ Dependency Checks — alerts you to suspicious package.json changes
✅ cspell — catches spelling mistakes in code and docs
✅ Auto-commit — fixes issues and commits automatically

No more manual setup. No more forgetting to run formatters. Just install once and let it work.

Installation & Setup (2 minutes)

Step 1: Install PR CheckMate

npm install --save-dev pr-checkmate

That's it. You don't need to install ESLint, Prettier, or cspell separately. PR CheckMate includes them all.

Step 2: Initialize Configuration

npx pr-checkmate init

You'll be prompted to specify your source path:

? Where is your project source code? (Use arrow keys)
❯ src 
  app 
  Enter manually

This creates a pr-checkmate.json file:

{
  "sourcePath": "src"
}

Step 3: (Optional) Customize Configuration

PR CheckMate ships with sensible defaults, but you can customize:

ESLint rules — add your .eslintrc.js or eslint.config.mjs
Prettier config — add your .prettierrc
Spellcheck dictionary — add your cspell.json

If you have local configs, PR CheckMate automatically detects and uses them. Otherwise, it uses bundled defaults.

Running Checks Locally

Before pushing, run checks locally to catch issues early:

# Run all checks
npx pr-checkmate all

# Run specific checks
npx pr-checkmate lint         # ESLint only
npx pr-checkmate prettier     # Format code
npx pr-checkmate deps         # Check dependencies
npx pr-checkmate spellcheck   # Spell check

Real Example Output

🚀 Running job: all
🔍 Running ESLint...
📋 Using local ESLint config
✅ ESLint passed

📦 Checking dependencies...
✅ Dependencies OK

🎨 Running Prettier...
📋 Using local Prettier config
✅ Prettier completed

🔤 Running spellcheck...
📦 Using pr-checkmate cspell config
✅ Spellcheck passed

Integrating with GitHub Actions

This is where the magic happens. Set up automated checks on every pull request:

Create `.github/workflows/pr-quality.yml`

name: 🔍 PR Quality Checks

on:
  pull_request:
    branches: [main, develop]

jobs:
  quality-checks:
    runs-on: ubuntu-latest

    steps:
      - name: 📥 Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: 🔧 Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: 📦 Install dependencies
        run: npm ci

      - name: 🔍 Run PR CheckMate
        run: npx pr-checkmate all

What this does:

Triggers on every pull request to main or develop
Checks out your code
Sets up Node.js with caching (faster builds!)
Installs dependencies
Runs all PR CheckMate checks

Result

Now every PR is automatically validated. No manual intervention needed:

✅ Lint check passed
✅ Dependency check passed
✅ Prettier formatting verified
✅ Spellcheck passed

If any check fails, the PR is blocked until issues are fixed. This happens before code review even begins.

Advanced: Auto-fix and Auto-commit

Want PR CheckMate to fix issues automatically? Create a more advanced workflow:

name: 🔧 Auto-fix Code Issues

on:
  pull_request:
    branches: [main]

permissions:
  contents: write
  pull-requests: write

jobs:
  auto-fix:
    runs-on: ubuntu-latest

    steps:
      - name: 📥 Checkout code
        uses: actions/checkout@v4
        with:
          ref: ${{ github.head_ref }}

      - name: 🔧 Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: 📦 Install dependencies
        run: npm ci

      - name: 🔍 Run PR CheckMate
        run: npx pr-checkmate prettier

      - name: 💾 Commit changes
        run: |
          git config user.name "PR CheckMate Bot"
          git config user.email "bot@checkmate.dev"
          git add -A
          if ! git diff --cached --quiet; then
            git commit -m "style: auto-format code with Prettier"
            git push
          fi

This workflow:

Runs Prettier on every PR
Auto-commits formatting fixes
Pushes changes back to the PR

No more back-and-forth on formatting! 🎉

Real-World Example: Before and After

Before PR CheckMate

PR opened → 1st review → "add semicolons" → developer fixes → 2nd review 
→ "run prettier" → developer fixes → 3rd review → "spellcheck readme" 
→ developer fixes → 4th review → finally approved ❌ Takes 2-3 hours

After PR CheckMate

PR opened → Automated checks run → All issues fixed → ✅ Ready to review
→ Code review in 15 minutes → Merged

What Each Tool Does

🔍 ESLint (Linting)

Catches code issues before they cause bugs:

// ❌ ESLint catches these:
var x = 1;        // Should use const/let
if (x == 1) {}    // Should use ===
unused_var = 2;   // Unused variable

🎨 Prettier (Formatting)

Enforces consistent style automatically:

// Before Prettier
const obj={a:1,b:2,c:3}
const fn=(x)=>x*2

// After Prettier
const obj = { a: 1, b: 2, c: 3 };
const fn = x => x * 2;

📦 Dependency Check

Alerts to suspicious package.json changes:

{
  "name": "my-project",
  "version": "1.0.0",
  "dependencies": {
    // Added 50 new packages? ⚠️ Flag for review
    "random-package": "^1.0.0"
  }
}

🔤 cspell (Spellcheck)

Catches typos in code, docs, and JSON:

❌ "Dependancies" → ✅ "Dependencies"
❌ "occured" → ✅ "Occurred"
❌ "seperate" → ✅ "Separate"

Configuration: Customizing Rules

Using Your Own ESLint Config

Just create an eslint.config.mjs in your project root. PR CheckMate will use it:

// eslint.config.mjs
import tsPlugin from '@typescript-eslint/eslint-plugin';
import tsParser from '@typescript-eslint/parser';

export default [
  {
    files: ['**/*.ts', '**/*.tsx'],
    languageOptions: {
      parser: tsParser,
    },
    plugins: {
      '@typescript-eslint': tsPlugin,
    },
    rules: {
      '@typescript-eslint/no-explicit-any': 'error',
      'no-console': 'warn',
    },
  },
];

Custom Prettier Config

Create .prettierrc:

{
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "printWidth": 100,
  "tabWidth": 2
}

Custom Spellcheck Dictionary

Create cspell.json:

{
  "version": "0.2",
  "language": "en",
  "words": [
    "mycompany",
    "TypeScript",
    "ESLint"
  ],
  "ignorePaths": [
    "**/node_modules/**",
    "**/dist/**"
  ]
}

FAQ

Q: Do I need to install ESLint, Prettier, and cspell separately?
A: No! PR CheckMate bundles them all. Just install pr-checkmate and you're done.

Q: What if I already have ESLint configured?
A: PR CheckMate detects your local config and uses it automatically.

Q: Can I use this in monorepos?
A: Yes! Specify different source paths using pr-checkmate.json.

Q: Does it slow down my CI/CD pipeline?
A: No. Most checks complete in seconds. It's faster than manual reviews!

Q: Can I skip certain checks?
A: Yes, disable them in your workflow:

- name: Run only linting
  run: npx pr-checkmate lint

Q: What Node versions are supported?
A: Node 18.0.0 and above.

Getting Started Today

Install: npm install --save-dev pr-checkmate
Initialize: npx pr-checkmate init
Test locally: npx pr-checkmate all
Add to CI: Copy the GitHub Actions workflow above
Push: Enjoy automatic code quality checks! 🎉

The Bottom Line

Code quality shouldn't require manual effort. ESLint, Prettier, and spellchecks should just work automatically, before code review even begins.

PR CheckMate eliminates the friction. Your team can focus on what matters: solving problems, not debating semicolons.

Try it today. Your pull request reviews will never be the same.

🚀 Built a Full CI/CD Pipeline with Playwright + Docker + Allure in Just 2 Days

Artur DefToExplore — Thu, 13 Nov 2025 06:31:44 +0000

When I started this project, my goal was simple:
👉 to build a universal, self-contained CI/CD test pipeline that could run anywhere — locally or in the cloud — with just one command.

💡 The Idea
I wanted to connect everything a modern QA engineer needs into one reproducible environment:

Playwright (TypeScript) → for end-to-end UI tests
Docker → for clean, isolated execution
Allure & Playwright HTML reports → for beautiful test results
A shared NPM SDK library → for reusable logic and faster scaling

💬 In short — a full test platform that’s portable, modular, and ready to grow.
``
🧩 The Architecture
This setup consists of two repositories that work together:

🧠 1. sdk_automation
Published as an NPM package → sdk_automation on npm
This SDK contains all shared test logic — API helpers, MongoDB connectors, data generators, and utilities — covered by Jest unit tests for reliability.
Think of it as the “brains” of your automation.

🧪 2. qa-portfolio
This repository is the Playwright E2E test environment.

It uses:
Dockerfile + docker-compose.yml → for reproducible builds
Playwright test runner → for UI automation
Allure & HTML reports → for rich visual reporting
A single entry point command:

docker compose up --build -d; docker compose exec -w /work/playwright_ts playwright_ts sh -c "npm install && npx playwright test --reporter=html"

This builds, runs, and serves the full test report — no manual setup, no global dependencies.

⚙️ What Happens Under the Hood
When you run:
docker compose up --build
Here’s what happens step-by-step:
Docker builds the Playwright image
The SDK (npm package) installs automatically
Tests run inside the container using Playwright
HTML report is generated after completion
The report is auto-served via serve on port 8080
You can open it locally with:
start ./playwright_ts/playwright-report/index.html

🐳 Run from Docker Hub You can run the full Playwright + Docker + Allure CI/CD pipeline directly from Docker Hub — no cloning, no setup, just one command
docker run --rm -it mybono/qa-portfolio:latest

✅ One command → full CI/CD simulation.
Works on Windows, macOS, and Linux.
📊 The Result
Reusable SDK with strongly-typed logic
Automated E2E tests running in isolation
Beautiful Allure & Playwright reports
Fully reproducible Dockerized pipeline
Here’s a quick look at the Playwright HTML report output:

🧱 Tech Stack Overview
Layer Technology Purpose
Core Playwright + TypeScript UI testing framework
SDK Node.js NPM Package Shared logic and helpers
Reports Allure / Playwright HTML Test reporting
Environment Docker + docker-compose CI/CD containerization
DB MongoDB (via Docker) Test data layer

🧠 Lessons Learned
💡 1. Decouple test logic from frameworks — SDKs make scaling painless.
⚙️ 2. Docker ensures parity between local, CI, and cloud environments.
📊 3. Reports are key to visibility, not just decoration.
🚀 4. CI/CD begins with architecture — not Jenkins.

🔮 Next Steps

Add Playwright on Python for multi-language support
ADD Slack notifications

⭐ Star It, Fork It, Break It (Then Fix It)
If you like the idea — star the repos and join the journey!
🧩 qa-portfolio
📦 sdk_automation

[Boost]

Artur DefToExplore — Tue, 28 Oct 2025 16:48:40 +0000

Why Stable E2E and Integration Tests Matter — and How to Achieve It with Docker and a Slim Database Copy - DEV Community

Run tests in isolated Docker Compose stacks using a preview image of your app and a slim database...

dev.to

Why Stable E2E and Integration Tests Matter — and How to Achieve It with Docker and a Slim Database Copy

Artur DefToExplore — Sat, 27 Sep 2025 10:53:24 +0000

Run tests in isolated Docker Compose stacks using a preview image of your app and a slim database copy seeded with only the entities you actually need. This drastically reduces flakiness, shortens run times, and restores trust in your test suite.

Introduction

End-to-end (E2E) and integration tests are essential for maintaining confidence in your product. They validate critical user flows and system interactions. But when tests are flaky—intermittently failing for non-code reasons—they block releases, waste debugging hours, and erode trust.

This article shows a practical approach to stabilizing tests by running them inside Docker against a dedicated preview image of your application, connected to a slimmed-down copy of your database. The result is deterministic, fast, and repeatable test runs.

The Problem with Unstable Tests

Common sources of flakiness:

Shared environments: Tests hit a master/shared database that is large and constantly changing.
Uncontrolled data dependencies: Required entities go missing or drift over time.
Heavy databases: Full clones are slow to snapshot, restore, and migrate, especially in CI.
Environment drift: Library versions, services, or feature flags differ between dev/CI/prod.

The Solution: Isolated Docker Environment + Slim Database Copy

We improve stability by isolating everything per test run:

Preview Docker image of the app (built from the current branch/PR).
Dedicated database container (fresh per run) with a small, known-good dataset.
Deterministic seeding: A repeatable seed that contains only the minimum required entities and relationships.

Benefits: stable data, predictable behavior, faster setup, and fewer false negatives.

Reference Setup (Docker Compose)

Below is a minimal Compose file for a web app and a Postgres database. Adapt the service names, ports, and env variables to your stack.

version: "3.9"
services:
  app:
    image: ghcr.io/your-org/your-app:${GIT_SHA:-preview}
    depends_on:
      - db
    environment:
      NODE_ENV: test
      DATABASE_URL: postgres://testuser:testpass@db:5432/testdb
    ports:
      - "8080:8080"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 5s
      timeout: 2s
      retries: 20

  db:
    image: postgres:16
    environment:
      POSTGRES_USER: testuser
      POSTGRES_PASSWORD: testpass
      POSTGRES_DB: testdb
    ports:
      - "5433:5432"
    volumes:
      - db_data_test:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U testuser -d testdb"]
      interval: 5s
      timeout: 2s
      retries: 20

volumes:
  db_data_test:

Building a Preview Image

Build the preview image in CI from the current branch and tag it with the commit SHA:

# Example Node app
FROM node:20-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci

FROM node:20-alpine AS build
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app .
EXPOSE 8080
CMD ["node", "dist/server.js"]

Deterministic Seeding: a Slim DB Copy

A slim copy is not a full clone of master/prod. It is a curated dataset containing only the tables/rows needed for your test scenarios—users, roles, feature flags, minimal catalog data, etc.

Example (Postgres) seed

-- Minimal roles
INSERT INTO roles (id, name) VALUES 
  ('00000000-0000-0000-0000-000000000001', 'admin'),
  ('00000000-0000-0000-0000-000000000002', 'user')
ON CONFLICT (id) DO NOTHING;

-- Test user
INSERT INTO users (id, email, role_id, created_at)
VALUES ('10000000-0000-0000-0000-000000000001', 'testuser@example.com',
        '00000000-0000-0000-0000-000000000002', NOW())
ON CONFLICT (id) DO NOTHING;

-- Feature flags (only those required by flows under test)
INSERT INTO feature_flags (key, enabled)
VALUES ('checkout_v2', true)
ON CONFLICT (key) DO UPDATE SET enabled = EXCLUDED.enabled;

-- Domain entities essential for E2E flows
INSERT INTO products (id, name, price_cents)
VALUES (1, 'Sample Product', 1999)
ON CONFLICT (id) DO NOTHING;

Applying migrations and seeding in CI

Use a simple Makefile to orchestrate lifecycle steps:

.PHONY: up migrate seed test down

up:
    docker compose -f docker-compose.test.yml up -d --wait

migrate:
    # Replace with your migration tool, e.g., Prisma, Knex, Flyway, Liquibase
    docker compose -f docker-compose.test.yml exec -T app npm run migrate:up

seed:
    docker compose -f docker-compose.test.yml exec -T db \
      psql -U testuser -d testdb < seed/slim-seed.sql

# Example: Playwright/Cypress/WDIO/etc.
test:
    docker compose -f docker-compose.test.yml exec -T app npm run test:e2e

down:
    docker compose -f docker-compose.test.yml down -v

Then in CI (GitHub Actions example):

name: e2e
on: [pull_request]

jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build preview image
        run: |
          docker build -t ghcr.io/your-org/your-app:${{ github.sha }} .
      - name: Start stack
        run: |
          GIT_SHA=${{ github.sha }} make up
      - name: Migrate & seed
        run: |
          make migrate
          make seed
      - name: Run tests
        run: |
          make test
      - name: Teardown
        if: always()
        run: |
          make down

Generating a Slim Copy from a Large DB (Optional)

If you must derive your slim dataset from a large source, don’t clone everything. Extract only the minimal rows and maintain referential integrity.

Strategy A: Hand-crafted seed (recommended)

Write idempotent INSERT statements for the handful of entities you need.
Keep it in version control and review changes with tests.

Strategy B: Selective dump (Postgres example)

Use pg_dump with include lists and filters:

# Dump schema only (fast migrations)
pg_dump \
  --schema-only \
  --no-owner --no-privileges \
  "$DATABASE_URL" > schema.sql

# Dump minimal data for specific tables
pg_dump \
  --data-only \
  --table=roles \
  --table=feature_flags \
  --table=products \
  --column-inserts \
  "$DATABASE_URL" > minimal-data.sql

cat schema.sql minimal-data.sql > seed/slim-seed.sql

Strategy C: Programmatic export

Write a small script (Node/TS) that queries only the rows/columns needed and emits SQL/JSON fixtures.
Enforce stable IDs (UUIDs) for deterministic references across runs.

Tip: Keep seeds small (< a few hundred rows). If a test needs new data, expand the seed incrementally and add an assertion to prove it.

Running Tests Inside the Stack

Your test runner (e.g., Playwright, Cypress, WebdriverIO, Jest-integration) should:

Wait for app and DB health checks.
Use a single, known BASE_URL (e.g., http://app:8080).
Create transient test data per spec when necessary, or reuse the seeded fixtures.

Example Playwright config snippet:

import { defineConfig } from '@playwright/test';

export default defineConfig({
  use: {
    baseURL: process.env.BASE_URL || 'http://localhost:8080',
    trace: 'retain-on-failure',
    video: 'retain-on-failure',
  },
});

Run command:

BASE_URL=http://localhost:8080 npx playwright test

Troubleshooting Flakiness: A Short Checklist

Time: Replace arbitrary waits with explicit waits for network/DOM state.
Data: Ensure seeds are applied and idempotent; reset DB between specs if needed.
Isolation: No tests should depend on state from previous tests.
Clocks: Mock time if flows are time-dependent (tokens, expirations, cron).
External APIs: Stub/mirror third-party calls; don’t let them fail your CI.
Retries: Use test-level retries sparingly and only for known flaky endpoints.

Conclusion

Stable tests are the foundation of reliable delivery. By running E2E/integration tests in Docker against a preview app image and a slim database copy, you eliminate data drift and environment coupling. Your suites become faster, more deterministic, and far easier to trust.

In real-world practice, teams that adopted this approach saw a sharp drop in test failures caused by data or environment issues, and at the same time achieved a significant boost in test execution speed. Faster feedback cycles and fewer false alarms translate directly into developer productivity and higher confidence in releases.

If your team is battling flaky tests, try this approach. Start with a tiny, hand-crafted seed; automate migrations; and keep everything in Compose. The upfront effort pays back quickly in saved engineering time and safer releases.

Real-World Impact (Metrics Example)

Here’s a simplified before/after snapshot many teams observe when switching to Docker + slim DB copies:

Metric	Before (shared DB)	After (slim DB in Docker)
Average E2E run time	~45 min	~18 min
Flaky test failures	20–30% of runs	<5% of runs
Developer confidence	Low	High

Even approximate metrics like these make a strong case in articles and internal presentations.

Appendix: MongoDB Variant (Bonus)

For MongoDB, swap Postgres services/commands with Mongo images and mongorestore:

version: "3.9"
services:
  app:
    image: ghcr.io/your-org/your-app:${GIT_SHA:-preview}
    environment:
      MONGODB_URI: mongodb://testuser:testpass@mongo:27017/testdb?authSource=admin
    depends_on:
      - mongo

  mongo:
    image: mongo:7
    ports:
      - "27018:27017"
    environment:
      MONGO_INITDB_ROOT_USERNAME: testuser
      MONGO_INITDB_ROOT_PASSWORD: testpass

Seed example:

# JSON or bsondump fixtures kept small and versioned
mongorestore --uri "mongodb://testuser:testpass@localhost:27018/testdb?authSource=admin" \
  --drop ./seed/mongo/slim

DEV Community: Artur DefToExplore

pr-checkmate: Stop Debating Style and Start Coding

The Problem We All Face

The Real Cost of Manual Code Quality Checks

Introducing PR CheckMate

Installation & Setup (2 minutes)

Step 1: Install PR CheckMate

Step 2: Initialize Configuration

Step 3: (Optional) Customize Configuration

Running Checks Locally

Real Example Output

Integrating with GitHub Actions

Create .github/workflows/pr-quality.yml

Result

Advanced: Auto-fix and Auto-commit

Real-World Example: Before and After

Before PR CheckMate

After PR CheckMate

What Each Tool Does

🔍 ESLint (Linting)

🎨 Prettier (Formatting)

📦 Dependency Check

🔤 cspell (Spellcheck)

Configuration: Customizing Rules

Using Your Own ESLint Config

Custom Prettier Config

Custom Spellcheck Dictionary

FAQ

Getting Started Today

The Bottom Line

Automating Code Quality: Stop Debating Style and Start Coding

The Problem We All Face

The Real Cost of Manual Code Quality Checks

Introducing PR CheckMate

Installation & Setup (2 minutes)

Step 1: Install PR CheckMate

Step 2: Initialize Configuration

Step 3: (Optional) Customize Configuration

Running Checks Locally

Real Example Output

Integrating with GitHub Actions

Create .github/workflows/pr-quality.yml

Result

Advanced: Auto-fix and Auto-commit

Real-World Example: Before and After

Before PR CheckMate

After PR CheckMate

What Each Tool Does

🔍 ESLint (Linting)

🎨 Prettier (Formatting)

📦 Dependency Check

🔤 cspell (Spellcheck)

Configuration: Customizing Rules

Using Your Own ESLint Config

Custom Prettier Config

Custom Spellcheck Dictionary

FAQ

Getting Started Today

The Bottom Line

🚀 Built a Full CI/CD Pipeline with Playwright + Docker + Allure in Just 2 Days

[Boost]

Why Stable E2E and Integration Tests Matter — and How to Achieve It with Docker and a Slim Database Copy - DEV Community

Why Stable E2E and Integration Tests Matter — and How to Achieve It with Docker and a Slim Database Copy

Introduction

The Problem with Unstable Tests

The Solution: Isolated Docker Environment + Slim Database Copy

Reference Setup (Docker Compose)

Building a Preview Image

Deterministic Seeding: a Slim DB Copy

Example (Postgres) seed

Applying migrations and seeding in CI

Generating a Slim Copy from a Large DB (Optional)

Strategy A: Hand-crafted seed (recommended)

Strategy B: Selective dump (Postgres example)

Strategy C: Programmatic export

Running Tests Inside the Stack

Troubleshooting Flakiness: A Short Checklist

Conclusion

Real-World Impact (Metrics Example)

Appendix: MongoDB Variant (Bonus)

Create `.github/workflows/pr-quality.yml`

Create `.github/workflows/pr-quality.yml`