CosmWasm multi-contract testing framework

Overview

Multi Test: Test helpers for multi-contract interactions

Warning: Alpha Software Designed for internal use only.

This is used for testing cw-plus contracts, we have no API stability currently. We are working on refactoring it and will expose a more refined version for use in other contracts. (Ideally in cw-plus 0.9 or 0.10).

Use at your own risk

Let us run unit tests with contracts calling contracts, and calling in and out of bank.

This only works with contracts and bank currently. We are working on refactoring to make it more extensible for more handlers, including custom messages/queries as well as IBC.

Comments
  • chore: add custom address generator support to WasmKeeper

    chore: add custom address generator support to WasmKeeper

    This PR adds the option to use custom address generator with WasmKeeper (which by default uses the existing address generator).

    Rationale behind it being that some contracts, like ours, might perform address validations. In our case we need to use bech32-compatible addresses and the ones currently being generated (contract{n}) aren't such.

    opened by Tofel 4
  • feature: Support defining IBC-enabled and IBC keeper

    feature: Support defining IBC-enabled and IBC keeper

    This PR extends the efforts of #9, which added the foundations for adding custom IBC keeper and thus support IBC messages.

    This PR also makes it possible to compile cw-multi-test without the need of adding stargate as a required feature to cosmwasm-std, by defining mock versions of both the IBC and Governance keeper modules.

    opened by KirilMihaylov 1
  • Stargate messages

    Stargate messages

    Support for modules handling stargate messages - IBC and Gov. No implementation of particular modules - by default just FailingModule, but possible to overwrite with custom, so it is possible tot test contracts sending IBC messages.

    opened by hashedone 1
  • Fixes and tests for stargate messages

    Fixes and tests for stargate messages

    Follow up of #9

    • Added couple more bounds in multi-tests where defaults were taken in place of IBC/Gov
    • Added dispatching of Gov messages
    • Tests for both IBC and Gov messages
    opened by hashedone 0
  • minor: Expose `Ibc` trait for use by other crates

    minor: Expose `Ibc` trait for use by other crates

    Motivation: This would allow downstream crates to utilize the recently added IBC capabilities of the crate. As of now, there is no way to provide functioning handler for IBC messages.

    opened by KirilMihaylov 1
  • add token supply query

    add token supply query

    Pretty much self explanatory, I need to be able to query for the supply of a native token during testing.

    I don't know how to get around the non_exhaustive issue, that's why I've redefined the SupplyResponse struct.

    opened by 0xArbi 0
  • Fixed module set -> Chain of responsibility migration

    Fixed module set -> Chain of responsibility migration

    People are facing the problem that if they have a contract emitting IBC messages, it is technically impossible to test them - passing any IBC message through a router will always cause panic. It is semi-solved for staking/custom messages by a separate module for them to fail by default, but possible to overwrite their behaviour. For now, the problem exists for IBC, Stargate and Gov messages (so basically anything introduced via a stargate feature).

    Another problem is how staking is implemented - it just enables the stargate feature flag by default (enabling relevant features in cosmwasm-std, but what would happen if someone would explicitly disable it - via no-default-fetures? It would fail to compile because of a lack of staking-related types in cw-std).

    This approach of the fixed module set has proven to be difficult to maintain properly. I have another idea. Let's model a module like something accepting any cosmos message and handling it optionally - if it knows how to handle it, it will return a proper result. If not - it would return some None equivalent. If any module manages to handle the message, its processing is finished successfully.

    To make it easy, I would create two generic "modules" or better "handlers". DefaultHandler would take any message and report an "unhandled message" error. One called on the very end of a chain. The other one would be FallbackHandler<Module, Fallback>. The FallbackHandler tries to handle a message using Module, and if it fails, it delegates handling it to Fallback. Fallback is typically another FallbackHandler or DefaultHandler at the end - basically a simple linked list.

    Now to make it even better API-wise, FallbackHandler would take an even better form: FallbackHandler<T, Filter<T>, Module<T>, Fallback>, where Filter takes a Cosmos message, returning some Option<T>, and Module<T> is a handler taking a T (eg. BankMsg) handling it. If the filter returns Some, then only my Module is allowed to handle the message. Otherwise, it is forwarded further (so it is shortcut-break if there is an unsupported bank message in future).

    This also allows changing the handler for a particular message - as they are unique identified with T - it would allow keeping the same Api we have now with some defaults (bank, wasmkeeper), which can be substituted with custom messages. It would also allow easily feature-enable some other implementations in future or allow others to provide custom implementation of modules not yet implemented in MT at all, under some feature flags.

    Any thoughts? I am happy to provide PoC of that.

    enhancement 
    opened by hashedone 7
  • cw_multi_test: accept closures in new()

    cw_multi_test: accept closures in new()

    The current implementation makes two restrictive decisions:

    1. The only way to create a wrapper is to pass function pointers (can't pass closures or any ol impl Fn)
    2. All the fields are private

    The internal new() creator is able to create a closure from the passed-in function pointer, but the current setup disallows the caller to do this too. e.g. it may want to wrap functions before passing them in.

    Suggestion: change the new() functions to accept any impl Fn

    edit: the Contract trait is pub so making the fields on ContractWrapper wouldn't add much. The real blocker is using the simple new() methods with closures being passed in

    opened by dakom 3
  • Support multiple custom messages / queries

    Support multiple custom messages / queries

    Multitests relying on TgradeApp must now (since cw-plus 0.12.1) use TgradeQuery. Because TgradeQuery is defined at the app level.

    This imposes some restrictions to our test code, in that we cannot in principle call contracts that don't implement the custom TgradeQuery.

    There are some workarounds already, like the TgradeWrapper::new_with_empty constructor, and the associated with_sudo/reply/migrate_empty builder-like helpers.

    It would simplify and generalise testing considerably if the message / query type could be specified at least at the contract level (i.e. in or as part of the store_code call). That would still require that all the entry points for that contract are of the same type. But, it will allow for easy heterogeneous "contracts with custom message" multi tests. And will be better suited for the future, in which we can have contracts with more than one custom message type (besides Empty).

    Doing this could be daunting, though, as this custom type is currently associated to everything from app and deps to responses.

    Related issues / comments:

    • https://github.com/CosmWasm/cw-plus/pull/660#issuecomment-1043177477
    • https://github.com/confio/tfi/pull/68
    • https://github.com/confio/poe-contracts/pull/103#issue-1137254582
    • https://github.com/confio/poe-contracts/pull/109
    opened by maurolacy 5
  • Add IBC support to multi-test

    Add IBC support to multi-test

    We now have support for Custom Msg and Queries, and an easy way to plug in Staking and Distribution support. (#266)

    One missing feature is being able to simulate IBC calls between 2 apps. This will require significant changes to the App structure and some coordinator that controls 2 apps. Rather than hide this as a checkbox, it makes sense to pull it into a full-blown issue to discuss.

    opened by ethanfrey 8
Owner
CosmWasm
Secure Multi-Chain Smart Contracts on the Cosmos SDK
CosmWasm
A simple example demonstrating cross-contract calls in CosmWasm smart contracts

Cross-contract calls This tutorial demonstrates cross-contract calls with CosmWasm v1. Overview An end user calls the reservation contract to register

csli Tools 3 Sep 12, 2022
A Multi-chain Decentralized Exchange (DEX) built on CosmWasm for the WYND DAO.

WynDex A Multi-chain Decentralized Exchange (DEX) built on CosmWasm for the WYND DAO. Overview License The initial pool types were copied from astropo

null 7 Jan 31, 2023
Testing a smart contract on the Solana blockchain

Environment Setup Install Rust from https://rustup.rs/ Install Solana from https://docs.solana.com/cli/install-solana-cli-tools#use-solanas-install-to

Maurice 1 Oct 25, 2021
A basic contract to facilitate multi-hop FIN swaps

Fin Multi A basic contract designed to support consolidation of staking "dust" into a single asset, via FIN Market Swaps. ExecuteMsg requires a Vec<Ve

Kujira 2 Oct 11, 2022
Examples and helpers to build NFT contracts on CosmWasm

CosmWasm NFTS This repo is the official repository to work on all NFT standard and examples in the CosmWasm ecosystem. cw721 and cw721-base were moved

CosmWasm 147 Jan 4, 2023
My code for the terra.academy course on CosmWasm smart contracts

CosmWasm Starter Pack This is a template to build smart contracts in Rust to run inside a Cosmos SDK module on all chains that enable it. To understan

Alex Incerti 0 Nov 7, 2021
A CosmWasm Tutorial by Terra Academy.

CosmWasm Starter Pack This is a template to build smart contracts in Rust to run inside a Cosmos SDK module on all chains that enable it. To understan

Tantatorn Suksangwarn 1 Dec 24, 2021
Beaker helps simplify CosmWasm development workflow.

Beaker Beaker makes it easy to scaffold a new cosmwasm app, with all of the dependencies for osmosis hooked up, interactive console, and a sample fron

null 62 Dec 29, 2022
A gRPC-based scripting library for interacting with CosmWasm smart-contracts.

Cosmos Rust Script Smart contract scripting library to ease CosmWasm smart contract development and deployment. cosm-script is inspired by terra-rust-

null 11 Nov 3, 2022
Organized, flexible testing framework for Rust

Stainless Stainless is a lightweight, flexible, unopinionated testing framework. Note that stainless currently requires the nightly version of the Rus

Jonathan Reem 455 Dec 5, 2022
Substrate NFT !ink smart contract base

Substrate !ink NFT simple implementation This is a simple working version of base NFT smart contract written using latest (as of this date) !ink 3.0.0

POLK4.NET 14 Dec 3, 2022
clockchain is a system for benchmarking smart contract execution times across blockchains.

Clockchain Clockchain is a research tool for benchmarking smart contract execution times across blockchains using Arcesco-- a block-chain agnostic ins

Zeke Medley 7 Oct 3, 2022
clockchain is a system for benchmarking smart contract execution times across blockchains.

Clockchain Clockchain is a research tool for benchmarking smart contract execution times across blockchains using Arcesco-- a block-chain agnostic ins

zeke 7 Oct 3, 2022
The NFT smart contract powering xyz on Terra

xyz NFT Contract This repository contains the core NFT smart contract that implements xyz, a base layer for metaverses on the Terra blockchain. The xy

null 16 Sep 25, 2022
An example smart contract that builds on top of xyz

xyz Guestbook Tutorial Contract This repository contains an example smart contract that illustrates how to build on top of the xyz NFT contract. This

null 5 Apr 4, 2022
Simple template for building smart contract(Rust) and RPC Client(web3.js) on Solana (WIP) ⛏👷🚧⚠️

Solana BPF Boilerplate Simple template for building smart contract(Rust) and RPC Client(web3.js) on Solana This boilerplate provides the following. Si

ono 6 Jan 30, 2022
Smart Contract for Terra Name Service

TERRA NAME SERVICE CONTRACTS Terra Name Service is to create easy-to-remember names for your Terra address like ‘dokwon.ust’ instead of ‘terra1...whez

null 12 Nov 23, 2022
Secret contract for Anons project.

Snip-721 Protocal by Baedrik template with several edits Minting Limits mint() caps tokens max at 580 mint() will keep count of how many anons each ad

Stake or Die 14 Jul 9, 2022
Emerging smart contract language for the Ethereum blockchain.

Emerging smart contract language for the Ethereum blockchain.

null 1.4k Jan 9, 2023