Go to file
Anatolios Laskaris e31b2fd736
chore: Update renovate (#134)
Update renovate
2024-09-04 22:48:34 +04:00
.cargo ci: Prepare for E2E (#35) 2022-11-28 21:45:31 +03:00
.github chore: Update renovate (#134) 2024-09-04 22:48:34 +04:00
crates chore: move to AGPLv3 (#132) 2024-07-15 13:00:05 +03:00
docs Add developer notes re PR reviewing (#15) 2022-04-26 16:22:42 +03:00
examples chore: move to AGPLv3 (#132) 2024-07-15 13:00:05 +03:00
src chore: move to AGPLv3 (#132) 2024-07-15 13:00:05 +03:00
.gitignore Publish crates from repo as is (without version increment) (#35) 2021-05-14 18:07:40 +03:00
Cargo.lock chore(master): release marine-rs-sdk-test 0.16.1 (#125) 2024-02-29 14:26:03 +04:00
Cargo.toml chore: move to AGPLv3 (#132) 2024-07-15 13:00:05 +03:00
CHANGELOG.md chore(master): release marine-rs-sdk-test 0.16.1 (#125) 2024-02-29 14:26:03 +04:00
CONTRIBUTING.md chore: move to AGPLv3 (#132) 2024-07-15 13:00:05 +03:00
FluenceCLA.md chore: move to AGPLv3 (#132) 2024-07-15 13:00:05 +03:00
LICENSE chore: move to AGPLv3 (#132) 2024-07-15 13:00:05 +03:00
README.md chore: move to AGPLv3 (#132) 2024-07-15 13:00:05 +03:00
rust-toolchain.toml feat(deps)!: update to marine runtime with memory limits (#98) 2023-12-14 17:26:44 +03:00
rustfmt.toml update the main part to the new sdk 2020-07-01 00:50:56 +03:00

Marine Test Rust SDK

crates.io version

This SDK aims to help developers targeting Marine to test their Wasm modules and services because cargo test can't run such modules, but it's necessary for testing. To avoid that limitation, the SDK introduces the #[marine_test] macro that does much of the heavy lifting to allow developers to use cargo test as intended. That is, the #[marine_test] macro generates the necessary code to call Marine, one instance per test function, based on the Wasm module and associated configuration file so that the actual test function is run against the Wasm module, not the native code.

Usage

The core component of the SDK is the #[marine_test] macro that can wrap a test function, providing an experience similar to "vanilla" Rust. A wrapped function should receive a special object representing a module interface, let's see an example:

use marine_rs_sdk::marine;

pub fn main() {}

#[marine]
pub fn greeting(name: String) -> String {
    format!("Hi, {}", name)
}

#[cfg(test)]
mod tests {
    use marine_rs_sdk_test::marine_test;

    #[marine_test(config_path = "../Config.toml", modules_dir = "../artifacts")]
    fn test(greeting: marine_test_env::greeting::ModuleInterface) {
        let actual = greeting.greeting("John".to_string());
        assert_eq!(actual, "Hi, John");
    }
}

This example shows a simple module with one export function greeting and a test. The test function is wrapped with the #[marine_test] macro, which specifies a path to the config file (Config.toml) and the directory containing the Wasm module we obtained after compiling the project with the marine CLI build command. This macro generates the necessary glue code to instantiate Marine instance under the hood and call the greeting module loaded into it.

After we have our Wasm module and tests in place, we can proceed with cargo test.

In a setup without the Marine test suite, the greeting function will be compiled to native and then test natively, comparingly with the suite it will be compiled to Wasm, loaded into Marine, and only then called as a Wasm module.

More details can be found in this chapter of the Marine book.

Documentation

Repository structure

Support

Please, file an issue if you find a bug. You can also contact us at Discord or Telegram. We will do our best to resolve the issue ASAP.

Contributing

Any interested person is welcome to contribute to the project. Please, make sure you read and follow some basic rules.

License

All software code is copyright (c) Fluence Labs, Inc. under the AGPL v3 license.