CosmWasm multi-contract testing framework


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.

  • 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.

    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:

    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
Secure Multi-Chain Smart Contracts on the Cosmos SDK
CosmWasm/Sylvia counting contract w/ IBC enabled (Cosmos, Rust, CosmWasm, Sylvia)

CosmWasm/Sylvia counting contract w/ IBC enabled (Cosmos, Rust, CosmWasm, Sylvia) This repository contains counting contract created during the study

Alex Cryp 3 Nov 13, 2023
Template for multi-contract CosmWasm projects

CosmWasm Template Template for multi-contract CosmWasm projects How to Use Install cargo-make: cargo install --force cargo-make Run formatter: cargo m

null 11 Jan 28, 2023
CosmWasm-Examples is a collection of example contracts and applications built using the CosmWasm framework

CosmWasm-Examples is a collection of example contracts and applications built using the CosmWasm framework. CosmWasm is a secure and efficient smart contract platform designed specifically for the Cosmos ecosystem.

Vitalii Tsyhulov 20 Jun 9, 2023
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
An example CosmWasm contract for connecting contracts over IBC.

CosmWasm IBC Example This is a simple IBC enabled CosmWasm smart contract. It expects to be deployed on two chains and, when prompted, will send messa

ekez 64 Jun 21, 2023
A brand-new multi-scenarios smart contract compiler framework

The Smart Intermediate Representation The Smart Intermediate Representation(short for IR) project is a new compiler framework intended for smart contr

AntChainOpenLabs 62 Jan 2, 2024
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 Install Solana from

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 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
CosmWasm + zkVM RISC-V EFI template

cosmwasm-risc0-example CosmWasm + RISC-V zkVM gm example Overview CosmWasm RISC Zero This example exists to explore the patterns of use of CosmWasm an

barton 11 Jan 11, 2023
A blazingly fast compiling & optimization tool for CosmWasm smart contracts.

cw-optimizoor A blazingly fast alternative to CosmWasm/rust-optimizer for compiling & optimizing CW smart contracts. It's primarily meant to speed up

Sebastian Mandrean 37 Apr 15, 2023
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
MLIR Rust multi-level compiler framework

MLIR-RS Multi-Level Intermediate Representation framework for Rust. What Modern programming language design is moving towards multi-level lowering to

Conrad Ludgate 16 May 29, 2023
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