running-tests

Guide SQLite and Postgres test workflows with just wrappers and tag decisions.

4|1|Updated Feb 4, 2024
One-click install
npx skills add https://github.com/Arx-Game/arxii --skill running-tests-arx-game
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: running-tests
Source: https://github.com/Arx-Game/arxii/tree/main/tools/skills/running-tests
Command: npx skills add https://github.com/Arx-Game/arxii --skill running-tests-arx-game

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Tests in this repository run in a two-tier model (SQLite fast tier and Postgres parity tier) to balance speed with CI parity.

Core Features & Use Cases

  • Guides running tests with just test-fast and just test-parity wrappers to speed feedback.
  • Outlines common pitfalls like --keepdb and decisions on when to apply @tag("postgres") parity checks.
  • Provides decision-making guidance for when to use the fast tier vs the parity tier and how to diagnose failures.

Quick Start

Start by running just test-fast <app> to validate inner-loop tests, or run just test-parity <app> to exercise parity against Postgres.

Frequently Asked Questions about running-tests

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run tests across SQLite and Postgres parity tiers?

Run tests across SQLite and Postgres parity tiers by executing just test-fast <app> for quick SQLite validation or just test-parity <app> to exercise Postgres parity checks against your application.

What is the difference between the fast tier and the parity tier in testing?

The testing fast tier uses SQLite for rapid inner-loop feedback, while the parity tier uses Postgres to ensure CI parity. The fast tier prioritizes execution speed, whereas the parity tier validates consistency across database engines.

When should I apply the @tag("postgres") decorator to a test?

Apply the @tag("postgres") decorator when a test specifically requires Postgres behavior to validate parity. It distinguishes tests that must run in the Postgres parity tier from standard SQLite fast tier checks.

Why does using --keepdb cause test failures in CI workflows?

Using --keepdb can cause test failures by retaining stale schema or data between runs, breaking isolation. The workflow provides guardrails to avoid these pitfalls and ensure clean database execution states.

What is the recommended workflow for diagnosing test inconsistencies between SQLite and Postgres?

To diagnose test inconsistencies, run just test-fast to validate SQLite, then just test-parity to reproduce Postgres failures. Compare outputs to identify parity gaps and apply @tag("postgres") where needed.