Adding Tests And Ci
Where a new test belongs, how to write a browser E2E test that fails when the feature...
Install
npx skills add BuilderIO/agent-native --skill adding-tests-and-ci -g -a claude-code -y- Repository
- BuilderIO/agent-native7.6k
- Category
- Design
- Updated
- 3d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Where a new test belongs, how to write a browser E2E test that fails when the feature breaks, and how to scope CI jobs, steps, and workflow triggers so they run only when a change can affect them. Use when adding, moving, or writing a test (including Design E2E specs), adding or changing a CI job, step, or workflow, or when a job is slow or runs on unrelated changes.
Adding Tests and CI
Why this is a cost question
Every agent-native workflow draws on one org-wide pool of GitHub-hosted runners.
On the Team plan it held 60 concurrent jobs, and on 2026-09-29 the Fast tests
gate waited a median 445 s just for a slot. BuilderIO moved to Enterprise
Cloud in October 2026, which raises the pool to 500 jobs (50 macOS). Minutes
are free for this OSS repo; slots are shared with every private repo. Scope
still matters, because a job a change cannot affect delays other PRs once the
pool fills, but parallelism that cuts the critical path is now worth a slot.
scripts/ci-change-scope.ts is the one place that decides what a change runs.
It classifies the changed paths into a full or targeted run and emits one output
per check. ci.yml jobs gate on those outputs. A .github/** change, the
lockfile, root config, or a scripts/** change other than a guard script or
root script test forces a full run.
Adding a test
First decide whether the test should exist: test-audit owns that gate and
its junk patterns. This section covers where it lives and what runs it.
