gear-foundation/vara-skills

sails-gtest

Use when a builder needs the standard Gear/Vara Sails gtest loop for feature verification, debugging, or regression coverage. Do not use for live-network-only validation, deployment-first workflows, or non-Sails programs.

First seen Apr 4, 2026

Installation

$ npx skills add gear-foundation/vara-skills --skill sails-gtest

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from gear-foundation/vara-skills · top by installs.

npx skills add gear-foundation/vara-skills

Browse all from gear-foundation/vara-skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 17
License LICENSE
Default branch main
Open issues 1
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,705 B
  • docs SUMMARY.md 240 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 2 installs

SKILL.md

Sails Gtest

Goal

Run the Sails-first test loop with generated clients and explicit gtest evidence before any live-node smoke step.

Inputs

  • ../../assets/gtest-report-template.md — report format for gtest results
  • ../../references/gtest-cheatsheet.md — quick reference for gtest APIs
  • ../../references/gtest-patterns.md — common test patterns
  • ../../references/sails-cheatsheet.md — Sails patterns and APIs
  • ../../references/sails-gtest-and-local-validation.md — full gtest and validation guide
  • ../../references/gear-gas-reservations-and-waitlist.md — gas reasoning for tests
  • ../../references/scale-binary-decoding-guide.md — decoding raw reply bytes
  • ../../references/sails-syscall-mapping.mdSyscall::* API for gas, message, and execution context

Write the result to docs/plans/YYYY-MM-DD-<topic>-gtest.md.

Expected Loop

  1. Confirm the implementation target is ready for verification.
  2. Use generated clients or GtestEnv instead of hand-built payloads where the workspace supports them.
  3. If the test must go below generated clients, first decide whether the payload or reply bytes are Sails-routed, plain SCALE, or metadata-driven state output; then apply the raw mental model: sendbytes* returns a MessageId, runnext_block returns the BlockRunResult, and the reply evidence lives in the block result.
  4. Pick the right BlockRunMode and advance blocks explicitly when replies or deferred effects depend on progression.
  5. Use runtoblock when delayed work or timeout behavior spans multiple blocks.
  6. Assert behavior, replies, events, or accounting in the test result, not just compilation.
  7. Record failure mode, fix, and passing command output in the gtest note.
  8. Route to ../sails-local-smoke/SKILL.md only after the suite is green.

Common Pitfalls

  • Rust 2024 listener lifetime: Under edition 2024 capture rules, chaining generated-client calls into listen() can fail with "temporary value dropped while borrowed". In Sails 1.0 the service client implements Listener directly, so bind the service client before listening:

``rust let client = program.service_name(); let mut events = client.listen().await.unwrap(); ``

  • Program balance accounting in gtest: The deployed program account has an existential deposit. Absolute balance assertions like == wager or == 0 will fail even when the contract accounting logic is correct. Capture the initial balance after deploy and assert deltas relative to that baseline:

``rust let initialbalance = env.balanceof(programid); // ... perform actions ... let finalbalance = env.balanceof(programid); asserteq!(finalbalance - initialbalance, expecteddelta); ``

  • Missing block advancement: Forgetting to call runnextblock after sending a message means the reply is never processed. Always advance at least one block after send operations that expect replies.

Guardrails

  • Do not use green cargo test output without Sails-appropriate assertions as proof.
  • Do not start local-node smoke while gtest is still red.
  • Do not skip gas or value reasoning when tests depend on it.
  • Do not decode raw reply or event bytes as a bare business DTO until you have checked whether Sails routing framing is present.
  • Use #[sails_type] for test-only types that mirror service types, ensuring encoding/decoding matches on-chain behavior exactly.