From c0684f0b16fe1fdbad6be46fc544894ed7acc0fc Mon Sep 17 00:00:00 2001 From: boneyard93501 Date: Thu, 2 Sep 2021 06:45:25 +0000 Subject: [PATCH] GitBook: [2.0.0] 23 pages modified --- knowledge_aquamarine/marine/marine-rs-sdk.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/knowledge_aquamarine/marine/marine-rs-sdk.md b/knowledge_aquamarine/marine/marine-rs-sdk.md index eac6b33..694b6cc 100644 --- a/knowledge_aquamarine/marine/marine-rs-sdk.md +++ b/knowledge_aquamarine/marine/marine-rs-sdk.md @@ -333,8 +333,8 @@ Since we are compiling to a wasm32-wasi target with `ftype` constrains, the basi Let's have a look at an implementation example: ```rust -use fluence::marine; -use fluence::module_manifest; +use marine_rs_sdk::marine; +use marine_rs_sdk::module_manifest; module_manifest!(); @@ -350,13 +350,13 @@ mod tests { use fluence_test::marine_test; # 2 #[marine_test(config_path = "../Config.toml", modules_dir = "../artifacts")] # 3 - fn empty_string() { + fn empty_string(greeting: marine_test_env::greeting::ModuleInterface) { let actual = greeting.greeting(String::new()); # 4 assert_eq!(actual, "Hi, "); } #[marine_test(config_path = "../Config.toml", modules_dir = "../artifacts")] - fn non_empty_string() { + fn non_empty_string(greeting: marine_test_env::greeting::ModuleInterface) { let actual = greeting.greeting("name".to_string()); assert_eq!(actual, "Hi, name"); } @@ -364,11 +364,11 @@ mod tests { ``` 1. We wrap a basic _greeting_ function with the `[marine`\] macro which results in the greeting.wasm module -2. We wrap our tests as usual with `[cfg(test)]` and import the fluence _test crate._ Do **not** import _super_ or the _local crate_. -3. Instead, we apply the `[marine_test]` to each of the test functions by providing the path to the config file, e.g., Config.toml, and the directory containing the Wasm module we obtained after compiling our project with `marine build`. It is imperative that project compilation proceeds the test runner otherwise there won't be the required Wasm file. -4. The target of our tests is the `pub fn greeting` function. Since we are calling the function from the Wasm module we must prefix the function name with the module namespace -- `greeting` in this example case. +2. We wrap our tests as usual with `[cfg(test)]` and import the marine _test crate._ Do **not** import _super_ or the _local crate_. +3. Instead, we apply the `[marine_test]` macro to each of the test functions by providing the path to the config file, e.g., Config.toml, and the directory containing the Wasm module we obtained after compiling our project with `marine build`. Moreover, we add the type of the test as an argument in the function signature. It is imperative that project build precedes the test runner otherwise the required Wasm file will ne missing. +4. The target of our tests is the `pub fn greeting` function. Since we are calling the function from the Wasm module we must prefix the function name with the module namespace -- `greeting` in this example case as specified in the function argument. -Now that we have our Wasm module and tests in place, we can proceed with `cargo test --release.` Note that using the `release`vastly improves the import speed of the necessary Wasm modules. +Now that we have our Wasm module and tests in place, we can proceed with `cargo test --release.` Note that using the `release`flag vastly improves the import speed of the necessary Wasm modules. ### Features