Agent skill

Testing

by ar-io in ar-io/ar-io-node

Decision guide for testing in the ar-io-node repo — which test layer to use, how to run it, and which helpers to reach for.

AGPL-3.0Auto-check: notesTesting & QA

Install Testing

skills CLI
$ npx skills add ar-io/ar-io-node --skill testing -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install ar-io/ar-io-node testing --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/ar-io/ar-io-node.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/testing .claude/skills/testing && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
testing
GitHub stars
127
Token cost
~2.6k tokens
SKILL.md length
1,099 words
Files
1
Skills in repo
3
Repo updated
First seen
Licence
AGPL-3.0

At a glance

Decision guide for testing in the ar-io-node repo — which test layer to use, how to run it, and which helpers to reach for.

  • Works in 5 steps: yarn service:stop → rm logs/service.log && touch… → yarn service:start → …
  • Writing a new test
  • SKILL.md covers Layer decision, Running tests, Writing unit tests and Writing e2e tests, plus 5 more sections
  • Calls yarn and node; needs ADMIN_API_KEY

What it does

Testing is an agent skill from ar-io/ar-io-node. Decision guide for testing in the ar-io-node repo — which test layer to use, how to run it, and which helpers to reach for. Use when writing a new test, picking a layer (unit / property / e2e / auto-verify / parquet integration / load test), running the suite or a single file, debugging a test failure, or when a schema or pipeline change needs cross-source verification. Triggers: "write a test for X", "run the tests", "which test layer", "run e2e", "run auto-verify", "load test the gateway", "test parquet…

Its SKILL.md is about 2.6k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA, covering DataFrames, End-to-end testing and Load testing. It works with ClickHouse, GraphQL, SQLite and TypeScript. The repository describes itself as: A scalable and modular gateway built for the permaweb atop the Arweave permanent data storage network. The licence is AGPL-3.0.

When your agent uses it

  • Writing a new test
  • Picking a layer (unit / property / e2e / auto-verify / parquet integration / load test)
  • Running the suite
  • Debugging a test failure

Example prompts

  • “write a test for X”
  • “run the tests”
  • “which test layer”
  • “/testing”

Requirements

  • Docker
  • A credential in ADMIN_API_KEY

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. yarn service:stop
  2. rm logs/service.log && touch logs/service.log (JSONL log; easier to diff when empty)
  3. yarn service:start
  4. Exercise the feature.
  5. yarn service:logs or tail logs/service.log; OTEL spans land in logs/otel-spans.jsonl.

What it can do on your machine

Read from SKILL.md and the folder at commit 9decdeb. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • yarn
    • node

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use yarn, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • ADMIN_API_KEY

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Testing loads about 2.6k tokens when it runs. Until then it costs about 140 tokens; SKILL.md has 1,099 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~140
When it runs · the whole SKILL.md, loaded when a task matches
~2.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NoteMentions a .env fileSKILL.md:34
    :indexing` | Auto-verify run. Driven by `.env` + `AUTO_VERIFY_*` vars. |
  • NoteMentions a .env fileSKILL.md:110
    hrough `scripts/service`**, which reads `.env`. `BACKGROUND_RETRIEVAL_ORDER` governs bundle reachability during unbundli

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from ar-io/ar-io-node at commit 9decdeb, republished under its AGPL-3.0 licence (© ar-io). 1,099 words, ~2,597 tokens.

Download SKILL.mdSave it as .claude/skills/testing/SKILL.md (or your agent's skills folder).
name
testing
description
Decision guide for testing in the ar-io-node repo — which test layer to use, how to run it, and which helpers to reach for. Use when writing a new test, picking a layer (unit / property / e2e / auto-verify / parquet integration / load test), running the suite or a single file, debugging a test failure, or when a schema or pipeline change needs cross-source verification. Triggers: "write a test for X", "run the tests", "which test layer", "run e2e", "run auto-verify", "load test the gateway", "test parquet export", "test against a running service".

Testing in ar-io-node

Layer decision

Pick the narrowest layer that can fail on the change.

LayerLives inRunnerWhen to use
Unitsrc/**/*.test.tsyarn test / yarn test:file <path>Pure logic, SQL wrappers, filters, route handlers (with supertest), middleware, data-source composition. Default choice.
Propertysrc/**/*.property.test.tssame as unitInvariants: determinism, output shape, distribution, round-trip. Uses fast-check. See src/lib/cdb64.property.test.ts for pattern.
E2Etest/end-to-end/*.test.tsyarn test:e2eFull request lifecycle through real containers: admin APIs, ArNS, bundler sidecar, webhook delivery, moderation, Prometheus metrics. Requires Docker.
Auto-verifysrc/tests/auto-verify/yarn test:auto-verify:indexingCross-source indexing reconciliation (SQLite / Parquet / bundle-parser / ClickHouse). Use after schema changes to stable_* tables, the Parquet export, or ClickHouse transactions.
Parquet / ClickHouse scriptsscripts/tests/parquet/test-*bash, run directlyParquet export correctness & perf, ClickHouse import pipeline, TTL rules loader. Operate against a populated local DB.
Load / stabilitytools/test-chunk-retrieval, tools/test-data-retrievalbash, run directlyStress endpoints for FD leaks, ECONNRESET patterns, p99 latency. Needs a running gateway.
GraphQL perf probetest/perf/gql-perfbash, GRAPHQL_URL=… ./test/perf/gql-perfAd-hoc timing comparisons across gateway endpoints.
Torrent engine contractsrc/index-swarm/transport/contract.test.tsunit always; against a real engine with INDEX_SWARM_E2E_ENGINE_URLThe TorrentTransport contract. Runs against the in-memory fake in yarn test; set the env vars in the file's header to also run it against a real qBittorrent (turn its IP filter off, or its WebSeed test is blocked). Needed for any change to an adapter under src/index-swarm/transport/.

Escalate when a change crosses boundaries. A unit test on a SQL wrapper is not enough if the change also alters the stable_* schema — add or update an auto-verify adapter. A unit test on the Parquet exporter isn't enough if row counts could drift — run scripts/tests/parquet/test-parquet-export.

Running tests

CommandWhat it does
yarn testAll unit+property tests, sequential (--test-concurrency 1).
yarn test:file src/foo/bar.test.tsSingle unit test file. Pass multiple paths if needed.
yarn test:coverageFull suite with HTML + text coverage via c8.
yarn test:file:coverage <path>Single file with coverage.
yarn test:e2eAll e2e tests. Builds the core image unless USE_PREBUILT_IMAGE=true.
yarn test:auto-verify:indexingAuto-verify run. Driven by .env + AUTO_VERIFY_* vars.
yarn lint:check / yarn lint:fixESLint.
yarn duplicate:check / yarn deps:cijscpd and madge circular-dep gate.

Tag filtering (unit + e2e): wrap test bodies with isTestFiltered(tags) from test/utils.ts and set TEST_ONLY_TAGS=slow,integration or TEST_SKIP_TAGS=flaky. CI runs e2e with TEST_SKIP_TAGS=flaky.

Single e2e file: yarn test:file test/end-to-end/indexing.test.ts works — test:file just forwards args to node --test.

Writing unit tests

  • Test runner: node:test (describe, it, before, after, beforeEach). Imports: import { describe, it } from 'node:test'; import assert from 'node:assert'; (or import { strict as assert } from 'node:assert').
  • Logger — always createTestLogger() from test/test-logger.ts. Never winston.createLogger({ silent: true }). Test output goes to logs/test.log (overwritten each run), not the console.
  • SQLite tests: import the shared handles from test/sqlite-helpers.ts (coreDb, dataDb, bundlesDb, moderationDb). The helper creates fresh DBs from test/*-schema.sql in before and truncates all tables in afterEach. Do not construct your own Sqlite instance.
  • Schema files are generated. If a migration changes a stable_* or new_* table, regenerate with ./test/dump-test-schemas (requires populated data/sqlite/*.db) and commit the result.
  • Stubs & fixtures: test/stubs.ts (ArweaveChainSourceStub, manifest streams, ANS-104 bundle stream), test/mock_files/ (txs, manifests, block id maps), test/mocks/ (e.g. mock-redis-token-bucket.ts).
  • HTTP handlers: mount the router on an Express app and drive it with supertest. Pattern in src/middleware/httpsig.test.ts, src/routes/data/handlers.test.ts.
  • Property tests: fast-check is in devDeps. Use .property.test.ts suffix to signal intent. Fix a seed when collisions/distribution matter; keep numRuns modest so the suite stays under a minute.

Writing e2e tests

  • Use composeUp() / cleanDb() from test/end-to-end/utils.ts. It wraps DockerComposeEnvironment (testcontainers) around the real docker-compose.yaml with sensible defaults and exposes START_HEIGHT, STOP_HEIGHT, filters, and ADMIN_API_KEY='secret'.
  • USE_PREBUILT_IMAGE=true reuses a pre-built core image (CI does this). Local runs rebuild from the Dockerfile.
  • Wait helpers in the same file: waitForBlocks, waitForBundleToBeIndexed, waitForTxToBeIndexed, waitForDataItemToBeIndexed, waitForLogMessage. Prefer these over hand-rolled polling.
  • Tear down with compose.down() in after(...). Forgetting this leaks containers across runs and tends to manifest as port conflicts on 4000/5432/8123.
Show full SKILL.md (473 more words)Show less

Auto-verify

See docs/auto-verify.md for the full spec. Key triggers:

  • Schema change to stable_blocks / stable_transactions / stable_data_items (or their tag tables) → update the matching adapter under src/tests/auto-verify/sources/ and the canonical types in src/tests/auto-verify/types.ts.
  • Parquet export schema change → same, update ParquetSource.
  • ClickHouse transactions schema change → update ClickHouseSource and the table-cleanup list in gateway-control.ts's cleanClickHouseTables.

A silent adapter divergence shows up as field_mismatch / missing_in_source discrepancies rather than a build error, so the adapters are the first thing to re-verify after a schema change.

Run knobs: AUTO_VERIFY_ITERATIONS=N to shuffle and sample, AUTO_VERIFY_FAIL_FAST=true while iterating, AUTO_VERIFY_PRESERVE_CACHE=false only when changing a data.db migration.

Parquet / ClickHouse integration scripts

All under scripts/tests/parquet/. They assume a populated data/sqlite/ and run the real export binary:

ScriptUse for
test-parquet-exportSmall export + --verifyCount. First thing to run after changing scripts/parquet-export or a projected column.
test-parquet-fullL1+L2, bigger range. Catches per-partition edge cases.
test-parquet-performanceSweep partition sizes (5/10/25/50). Use when changing batching.
test-timing / test-query-timing[TIMING] breakdowns; use to isolate slow SQL in export.
test-data-integrityPost-hoc: verify field formats in an export directory.
test-clickhouse-integrationEnd-to-end export → clickhouse-import. Run after schema or loader changes.
test-clickhouse-ttl-rulesTTL rules loader only (PE-9058 path).

They read config via scripts/lib/common.sh (load_env, load_clickhouse_config). Height ranges are hardcoded to ranges present in the fixture DB — if data/sqlite/core.db doesn't cover the range, expect empty results rather than a failure.

Load / stability tests

  • tools/test-chunk-retrieval — stress /chunk/{offset}. Supports --concurrency, --duration, --track-fds <pid> for FD leak detection on Linux. Output includes p50/p95/p99, status code histogram, resource-exhaustion flag (EMFILE, ENFILE, ENOMEM).
  • tools/test-data-retrieval — same shape, for /raw/{id} and similar. See tools/README.md for flags.

Use these when validating a fix for a reported leak or a latency regression, not as part of the normal dev loop.

Iterating against a running service

When a test needs the real service running (load tools, parquet scripts, ad-hoc curl):

  1. yarn service:stop
  2. rm logs/service.log && touch logs/service.log (JSONL log; easier to diff when empty)
  3. yarn service:start
  4. Exercise the feature.
  5. yarn service:logs or tail logs/service.log; OTEL spans land in logs/otel-spans.jsonl.

Gotchas

  • Tests run sequentially (--test-concurrency 1). Don't add parallelism assumptions; don't rely on test isolation via parallelism.
  • sqlite-helpers.ts truncates in afterEach, not beforeEach. The first test in a file starts with an empty DB from the before hook; later tests inherit cleared-but-migrated state. Inserting in before is dangerous because afterEach will delete it.
  • bundle_formats is preserved across truncation (see the tbl_name != 'bundle_formats' filter). If a test depends on an empty bundle_formats, wipe it explicitly.
  • E2E fixtures are byte files in test/end-to-end/files/ (BDI, data items). Don't synthesize them at runtime.
  • Auto-verify's gateway spawns through scripts/service, which reads .env. BACKGROUND_RETRIEVAL_ORDER governs bundle reachability during unbundling, not ON_DEMAND_RETRIEVAL_ORDER — if unbundling stalls, check trusted-gateway reachability first.
  • Coverage reports land in coverage/ (c8). Don't commit.
  • Single-test focus: node:test has no .only. Use TEST_ONLY_TAGS or narrow via yarn test:file <path>; combine with --test-name-pattern if needed (pass through yarn test:file).

© ar-io, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/testing of ar-io/ar-io-node.

Open the folder on GitHubat commit 9decdeb

Compare with similar skills

Testing next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Testing compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Testing this skillar-io/ar-io-node127—~2.6kAutomated safety check: NotesAGPL-3.0
Playwright E2E Testingfugazi/test-automation-skills-agents247—~3.2kAutomated safety check: PassMIT
Manual Testhypequery/hypequery103—~618Automated safety check: PassCustom licence
ClickHouse RowBinary for Node.jsClickHouse/agent-skills544—~1.3kAutomated safety check: PassApache-2.0
Senior Backendalirezarezvani/claude-skills28k1 repos~3.8kAutomated safety check: PassMIT
API Testingfugazi/test-automation-skills-agents247—~1.5kAutomated safety check: PassMIT

Similar skills

  • Playwright E2E Testing

    fugazi/test-automation-skills-agents

    Author and maintain versioned Playwright (@playwright/test) TypeScript UI specs for browser user flows.

    247 GitHub stars~3.2k tokensUpdated 4 days ago
    Testing & QAAuto-check passed
  • Manual Test

    hypequery/hypequery

    Execute one of the model-runnable E2E test specs in testing/ (cli, datasets, serve, mcp, react) against a real ClickHouse instance.

    103 GitHub stars~618 tokensUpdated today
    DatabasesAuto-check passed
  • ClickHouse RowBinary for Node.js

    ClickHouse/agent-skills

    Generates TypeScript or JavaScript readers and writers for ClickHouse's RowBinary formats over HTTP in Node.js, after checking that RowBinary suits the data.

    544 GitHub stars~1.3k tokensUpdated 8 days ago
    DatabasesAuto-check passed
  • Senior Backend

    alirezarezvani/claude-skills

    Designs and implements backend systems including REST APIs, microservices, database architectures, authentication flows, and security hardening.

    28k GitHub starsUsed in 1 repo~3.8k tokens
    Backend & APIsAuto-check passed
  • API Testing

    fugazi/test-automation-skills-agents

    Test REST and GraphQL endpoint contracts using Playwright request fixture (TypeScript) or REST Assured (Java).

    247 GitHub stars~1.5k tokensUpdated 4 days ago
    Testing & QAAuto-check passed
  • E2E Test

    crowdin/crowdin-api-client-js

    Run end-to-end tests against the real Crowdin or Crowdin Enterprise API using credentials from .env.

    139 GitHub stars~893 tokensUpdated 5 days ago
    Testing & QAAuto-check: notes

More from ar-io/ar-io-node

  • Ar Io Gateway Operator

    ar-io/ar-io-node

    Operate any AR.IO node deployment — architecture, daily ops, diagnostics, and recurring pitfalls that apply to every operator.

    127 GitHub stars~8.2k tokensUpdated today
    Auto-check: notes
  • Release

    ar-io/ar-io-node

    Drive the AR.IO Node release process end-to-end — preflight checks, prepare commit, finalize with image SHAs, test docker compose profiles, tag & publish, and post-release cleanup.

    127 GitHub stars~4.2k tokensUpdated today
    Auto-check: notes

Categories

Questions about Testing

What does Testing do?

Decision guide for testing in the ar-io-node repo — which test layer to use, how to run it, and which helpers to reach for. Testing is an agent skill from ar-io/ar-io-node. Decision guide for testing in the ar-io-node repo — which test layer to use, how to run it, and which helpers to reach for.

When should I use Testing?

Testing fits situations like: writing a new test; picking a layer (unit / property / e2e / auto-verify / parquet integration / load test); running the suite; debugging a test failure.

How do I install Testing in Claude Code?

Run `npx skills add ar-io/ar-io-node --skill testing -a claude-code`. Or copy the skill folder (.claude/skills/testing in ar-io/ar-io-node) into .claude/skills/testing in your project. Claude Code loads it when a task matches its description.

How do I install Testing in Codex?

Run `npx skills add ar-io/ar-io-node --skill testing -a codex`. Or copy the skill folder (.claude/skills/testing in ar-io/ar-io-node) into .agents/skills/testing in your project. Codex loads it when a task matches its description.

Can I use Testing in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add ar-io/ar-io-node --skill testing -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/testing, .gemini/skills/testing, .github/skills/testing and .opencode/skills/testing in your project.

What does Testing need to run?

Going by SKILL.md and its folder, Testing needs the command-line tools its instructions call (yarn and node) and credentials named ADMIN_API_KEY. Our summary lists: Docker; A credential in ADMIN_API_KEY.

Does Testing access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Testing safe to install?

Our automated static check of SKILL.md found notes only (mentions a .env file), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Testing use?

Testing is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Testing use?

About 2.6k tokens (SKILL.md is roughly 10k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Testing?

Skills that share tags, products or a category with Testing: Playwright E2E Testing (fugazi/test-automation-skills-agents, 247 stars), Manual Test (hypequery/hypequery, 103 stars), ClickHouse RowBinary for Node.js (ClickHouse/agent-skills, 544 stars) and Senior Backend (alirezarezvani/claude-skills, 28k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Testing?

ar-io (a GitHub organization) maintains it in ar-io/ar-io-node, which has 127 GitHub stars. The repository holds 3 skills in this directory. The repository was last updated on October 7, 2026.

Source: ar-io/ar-io-node on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.