Run any Skill in Manus with one click

$pwd:

rust-testing

Name: Rust Testing
Author: axone-protocol

// Patterns for Rust testing in Axone CosmWasm contracts. Use when adding unit tests, integration tests, data-driven cases, or coverage-oriented test scenarios.

Run Skill in Manus

$ git log --oneline --stat

stars:123

forks:20

updated:March 28, 2026 at 19:44

File Explorer

3 files

SKILL.md

readonly

name	rust-testing
description	Patterns for Rust testing in Axone CosmWasm contracts. Use when adding unit tests, integration tests, data-driven cases, or coverage-oriented test scenarios.
license	BSD-3-Clause
metadata	{"author":"axone.xyz","version":"1.0"}

Rust Testing

Coverage Targets

Component	Target
Handlers	100%
State operations	100%
Error paths	90%+
Message parsing	80%+
Overall	90%+

Minimum Cases to Cover

For handlers: cover the happy path, parameter variations, error paths, and resulting state changes.
For queries: cover empty state, populated state, pagination behavior, and non-existent items.
For state transitions: cover initial state, updates after execute, and persistence across operations.

Running Tests

# Run all unit tests
cargo make test-unit

# Run all tests (includes integration)
cargo make test

# Run tests with coverage
cargo make test-coverage

# Run specific test
cargo test test_name -- --nocapture

Coverage output is written to lcov.info.

Viewing Coverage

# Generate HTML report (requires lcov)
genhtml lcov.info --output-directory coverage/

# Or use cargo-llvm-cov directly
cargo llvm-cov --html --open

Test Design Rules

Isolate tests. Each test should set up its own environment.
Test contract behavior, not framework internals.
Assert exact errors when possible.
Cover edge cases such as zero values, empty strings, and upper bounds.
Prefer descriptive test names without a test_ prefix.
Use tuple-driven cases for simple matrices and structs only when the case shape needs named fields.

References

For cw-orch integration harness patterns and common integration scenarios, read integration-patterns.
For naming and data-driven test examples, read test-style.

related-skills.json

same repository

cosmwasm-contract.md

from "axone-protocol/contracts"

Axone contract structure and Abstract SDK patterns. Use when scaffolding or refactoring contracts, deciding layer boundaries, wiring AppContract entrypoints, or adding module metadata and replies.

2026-03-28123

deployment.md

from "axone-protocol/contracts"

Axone deployment workflows with cargo-make, cw-orch, and Abstract. Use when publishing modules, installing them on accounts, running local chain tasks, or inspecting deployments.

2026-03-28123

rust-contract-domain-modeling.md

from "axone-protocol/contracts"

Domain-driven modeling patterns for Axone contracts. Use when introducing domain concepts, encoding invariants, or deciding boundaries between domain, handlers, services, gateways, queries, and state.

2026-03-28123

rust-quality-gates.md

from "axone-protocol/contracts"

Repository quality gates for Rust and generated artifacts. Use when validating changes locally or before committing Rust, schema, or documentation updates.

2026-03-28123

api-design.md

from "axone-protocol/contracts"

Best practices for designing CosmWasm smart contract APIs. Use when defining message types, designing execute/query interfaces, or optimizing API ergonomics.

2026-03-28123

api-doc-comments.md

from "axone-protocol/contracts"

Guide for writing Rust doc comments that produce accurate generated contract documentation. Use when editing Instantiate/Execute/Query/Response types or any public schema-facing API.

2026-03-28123

package.json

"author": "axone-protocol"

"repository": "axone-protocol/contracts"

View GitHub Repository View Creator Repositories

$ install --global

$ download --local

Run Skill in Manus

$ useful --forSOC

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations15-1253L4

name	rust-testing
description	Patterns for Rust testing in Axone CosmWasm contracts. Use when adding unit tests, integration tests, data-driven cases, or coverage-oriented test scenarios.
license	BSD-3-Clause
metadata	{"author":"axone.xyz","version":"1.0"}

Rust Testing

Coverage Targets

Component	Target
Handlers	100%
State operations	100%
Error paths	90%+
Message parsing	80%+
Overall	90%+

Minimum Cases to Cover

For handlers: cover the happy path, parameter variations, error paths, and resulting state changes.
For queries: cover empty state, populated state, pagination behavior, and non-existent items.
For state transitions: cover initial state, updates after execute, and persistence across operations.

Running Tests

# Run all unit tests
cargo make test-unit

# Run all tests (includes integration)
cargo make test

# Run tests with coverage
cargo make test-coverage

# Run specific test
cargo test test_name -- --nocapture

Coverage output is written to lcov.info.

Viewing Coverage

# Generate HTML report (requires lcov)
genhtml lcov.info --output-directory coverage/

# Or use cargo-llvm-cov directly
cargo llvm-cov --html --open

Test Design Rules

Isolate tests. Each test should set up its own environment.
Test contract behavior, not framework internals.
Assert exact errors when possible.
Cover edge cases such as zero values, empty strings, and upper bounds.
Prefer descriptive test names without a test_ prefix.
Use tuple-driven cases for simple matrices and structs only when the case shape needs named fields.

References

For cw-orch integration harness patterns and common integration scenarios, read integration-patterns.
For naming and data-driven test examples, read test-style.

rust-testing

Rust Testing

Coverage Targets

Minimum Cases to Cover

Running Tests

Viewing Coverage

Test Design Rules

References

More from this repository

More from this repository

Rust Testing

Coverage Targets

Minimum Cases to Cover

Running Tests

Viewing Coverage

Test Design Rules

References