بنقرة واحدة
integration-tests
Write and run integration tests against a GenLayer environment.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Write and run integration tests against a GenLayer environment.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Entry point for Internet Court — the trust layer for agent-to-agent commerce. Use whenever an agent needs to transact with another agent or a paid service, or a user mentions agent payments, paid APIs (HTTP 402/x402), wallet custody or trust concerns, spending mandates, delegated permissions (ERC-7710/7715), escrow, agent identity or reputation (ERC-8004), negotiation between agents (A2A), agent jobs (ERC-8183), machine payments (MPP, AP2), supervision of agent behavior, revocation, verification, or dispute resolution (GenLayer) — even if they never say "Internet Court". Routes to the vendored protocol skills and connector skills in this package.
Connect GenLayer Intelligent Contract decisions to ERC-7710-style delegated authority. Use when an agent needs to design the interface, message schema, relayer/bridge path, EVM revocation controller, constraint updates, proof/finality assumptions, and failure handling that turn a GenLayer agent-performance review into ERC-7710 revocation or policy changes.
Internet Court adapter for GenLayer Intelligent Contract supervision. Use to specify agent-performance rubrics, evidence schemas, decision outputs, and ERC-7710 connector expectations, while delegating actual GenLayer contract writing, linting, testing, deployment, and CLI interaction to the official GenLayer skills at https://skills.genlayer.com/.
Design and implement demos combining x402 HTTP payments with ERC-7710 smart contract delegations and ERC-7715 wallet permission requests for subscriptions, bounded agent budgets, recurring spend, pay-per-use APIs, and agentic commerce.
0G Compute Network guide for decentralized AI inference, fine-tuning, and GPU services. Covers chatbots, image generation, speech-to-text, SDK integration (0g-serving-broker), processResponse API, broker.inference methods, CLI commands (0g-compute-cli), and account management. Use this skill for any 0G compute, 0G AI, or decentralized GPU question.
Use this skill when the user asks to list, create, inspect, update, disable, re-enable, or revoke AltLLM Portal API keys for external agents or applications. Do NOT use for wallet login, billing history, or payment links.
| name | integration-tests |
| description | Write and run integration tests against a GenLayer environment. |
| allowed-tools | ["Bash","Read","Write","Edit"] |
Run contracts against a real GenLayer environment (GLSim, Studio, or testnet) with full consensus validation.
# Against default network (from gltest.config.yaml)
gltest tests/integration/ -v -s
# Against specific network
gltest tests/integration/ -v -s --network localnet
gltest tests/integration/ -v -s --network studionet
gltest tests/integration/ -v -s --network testnet_bradbury
Always use -v -s for visible output during development.
from gltest import get_contract_factory
from gltest.assertions import tx_execution_succeeded
def test_full_flow():
factory = get_contract_factory("MyContract")
contract = factory.deploy(args=[])
# Write methods return transaction receipts
tx_receipt = contract.set_data(args=["hello"]).transact()
assert tx_execution_succeeded(tx_receipt)
# Read methods return values directly
result = contract.get_data(args=[contract.address]).call()
assert result == "hello"
ACCEPTED and FINALIZED are transaction lifecycle states, not proof that
contract execution succeeded. A transaction can be accepted and finalized with
an execution error, and failed execution applies no state changes. For deploy
transactions, failed execution means no contract is created.
Always assert tx_execution_succeeded(receipt) before reading state, checking
schema/code, or treating a missing contract as an infrastructure issue.
| Direct Mode | Integration Tests | |
|---|---|---|
| Speed | ~30ms | ~seconds to minutes |
| Server required | No | Yes (GLSim, Studio, or testnet) |
| Consensus | Leader only | Full leader + validators |
| Write methods | Return values directly | Return transaction receipts |
| Read methods | Return values directly | Use .call() |
| Mocking | mock_web() / mock_llm() | Real web/LLM calls |
Write methods (state-changing):
# .transact() submits and waits for consensus
tx_receipt = contract.method_name(args=[arg1, arg2]).transact()
assert tx_execution_succeeded(tx_receipt)
Read methods (view-only):
# .call() reads without transaction
result = contract.view_method(args=[arg1]).call()
contract_path: contracts/
networks:
localnet:
# GenLayer Studio running locally
studionet:
# studio.genlayer.com — gasless, no funding needed (0 GEN balance is fine)
testnet_bradbury:
accounts:
- "${ACCOUNT_PRIVATE_KEY_1}"
- "${ACCOUNT_PRIVATE_KEY_2}"
import pytest
@pytest.mark.slow
def test_expensive_operation():
"""Excluded by default. Run with: gltest -m slow"""
pass
pip install genlayer-test[sim], glsim --port 4000 --validators 5) — lightweight, no Docker, ~1s startup. Runs Python natively, not in GenVM. Good for fast iteration.genlayer up) — full GenVM, real consensus, Docker required. Validates runtime compatibility.Direct mode should cover most logic testing. Use integration tests for final validation before deploying.
Clear cache: rm -rf .gltest_cache
Run single tests during development:
gltest tests/integration/test_file.py::test_specific -v -s
When working with mock validators, convert to dicts:
transaction_context = {"validators": [v.to_dict() for v in mock_validators]}
studio.genlayer.com enforces per-IP limits: 60 req/min, 1000 req/hr, 10000 req/day. Limits aren't permanent — once tripped, further requests are rejected until the current window resets (next minute / hour / day cycle). Throttle batch tests, run heavy suites against localnet (GLSim or local Studio), or pace .transact() calls.
-32028 is the related pending-queue cap — up to 32 in-flight txs per sender; a separate cap also applies per contract to prevent flooding the shared Studio. Wait for receipts before submitting the next batch instead of firing in parallel.