Crates.io | drink-test-macro |
lib.rs | drink-test-macro |
version | 0.17.0 |
source | src |
created_at | 2023-10-23 10:25:26.657043 |
updated_at | 2024-04-03 10:26:25.756013 |
description | Procedural macro providing a `#[drink::test]` attribute for `drink`-based contract testing |
homepage | https://github.com/Cardinal-Cryptography/drink |
repository | https://github.com/Cardinal-Cryptography/drink |
max_upload_size | |
id | 1011189 |
size | 21,483 |
Dechained Ready-to-play ink! playground
DRink! is a toolbox for ink! developers that allows for a fully functional ink! contract development without any running node. It provides you with a unique, yet very powerful environment for interacting with contracts:
The key concept behind DRink! is to provide a nodeless environment. To understand it fully, we need to have a high-level overview of the Substrate architecture.
Note: While here we use Substrate-specific terms, these concepts are pretty universal and apply to at least most of the blockchain designs.
Any blockchain network participant runs a single binary, which is usually called a node or a host. It is responsible for the fundamental operations like:
When it receives a new transaction (or a block), it has to update the blockchain state. For that, it uses a state transition function, called a runtime. This is an auxiliary binary, which serves as the core logic function, taking as an input the current state and a transaction, and returning the updated state.
In case the transaction is some smart contract interaction, the runtime has to execute it within an isolated environment. (This is where the contract pallet comes into play and spawns a dedicated sandbox.)
As a result, we have a layered architecture resembling an onion (actually, there are a few layers more, but we don't need to dig that deep).
Depending on the part of technology stack involved, we can derive three main testing strategies for smart contracts.
Before DRink!, you could have used ink!'s native test framework to execute either unit tests (with #[ink::test]
macro) or end-to-end tests (with #[ink_e2e::test]
macro).
DRink! enabled the third option, i.e. quasi-end-to-end testing.
This paradigm is a peculiar compromise between the two other strategies. We give up the node layer (including networking, block production etc.), but we still have a fully functional runtime with attached storage. In other words, we keep bare blockchain state in-memory, and we can interact with it directly however we want.
This way, we gain full control over the runtime, sacrificing real simulation of the blockchain environment. However, usually, this is higly beneficial for the development process, as it allows for a much faster feedback loop, assisted with better insights into execution externalities.
You can use DRink! in three ways:
This way you gain access to full DRink! power in your test suites. Check our helpful and verbose examples in the examples directory.
drink
library is continuously published to crates.io, so you can use it in your project with either cargo add drink
or by adding the following line to your Cargo.toml
:
drink = { version = "0.8" }
Full library documentation is available at: https://docs.rs/drink.
Quick start guide is available here.
DRink! is already integrated with ink! and can be used as a drop-in replacement for the standard E2E testing environment. Just use corresponding argument in the test macro:
#[ink_e2e::test(backend = "runtime_only")]
to your test function and you have just switched from E2E testcase to quasi-E2E one, that doesn't use any running node in the background!
For a full example check out ink! repository.
We provide a CLI which puts DRink! behind friendly TUI. Below you can find a short demo of how it works. For more details, consult its README.
https://github.com/Cardinal-Cryptography/drink/assets/27450471/4a45ef8a-a7ec-4a2f-84ab-0a2a36c1cb4e
Similarly to drink
library, drink-cli
is published to crates.io as well.
You can install it with:
cargo install drink-cli