[marine_test]are the two primary features provided by the SDK. The
[marine]macro can be applied to a function, external block or structure. The
[marine_test]macro, on the other hand, allows the use of the familiar
cargo testto execute tests over the actual Wasm module generated from the service code.
[marine]macro to a function results in its export, which means that it can be called from other modules or AIR scripts. For the function to be compatible with this macro, its arguments must be of the
ftype, which is defined as follows:
[marine]macro can also wrap an
externblock. In this case, all functions declared in it are considered imported functions. If there are imported functions in some module, say, module A, then:
linkmacro (see examples below).
Marineby the moment the loading of module A starts. Module A cannot be loaded if at least one imported function is absent in
[marine]macro can wrap a
structmaking possible to use it as a function argument or return type. Note that
fluence::get_call_parameters()that returns an instance of the
CallParametersstructure defined as follows:
curl_requestfunction, which calls the imported curl binary in this case, to make http calls. Please note that we are wrapping the
externblock with the
[marine]macro and introduce a Marine-native data structure
MountedBinaryResultas the linked-function return value.
curl_requestwith testing, see below, the curl call needs to be marked unsafe, e.g.:
ftypeconstrains, the basic
cargo testis not all that useful or even usable for our purposes. To alleviate that limitation, Fluence has introduced the
[marine-test]macro that does a lot of the heavy lifting to allow developers to use
cargo testas intended. That is,
[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.
[marine-test]macro please add
marine-rs-sdk-testcrate to the
[marine]macro which results in the greeting.wasm module
[cfg(test)]and import the marine test crate. Do not import super or the local crate.
[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 be missing.
pub fn greetingfunction. Since we are calling the function from the Wasm module we must prefix the function name with the module namespace --
greetingin this example case as specified in the function argument.
cargo test --release.Note that using the
releaseflag vastly improves the import speed of the necessary Wasm modules.
testfunction with the
marine_testmacro by providing named service configurations with module locations. Based on its arguments the macro defines a
marine_test_envmodule with an interface to the services.
ServiceInterface::new()runs a new marine runtime with the service.
marine_test_env. The macro finds all structures used in the service interface functions and defines them in the corresponding submodule of
test_on_mod.rstab we can see another option — applying
mod. The macro just defines the
marine_test_envat the beginning of the module and then it can be used as usual everywhere inside the module.
marine_testmacro also gives access to the interface of internal modules which may be useful for setting up a test environment. This feature is designed to be used in situations when it is simpler to set up a service for a test through internal functions than through the service interface. To illustrate this feature we have rewritten the previous example:
Help -> Actions -> Experimental Futuresenable
Cargo.tomland build from IDE or press
Refresh Cargo Projectin Cargo tab.
Cargo.tomlto let plugin update code from generated files
build.rsrun again, but for the native target.
wasm32-wasiand tests are built for native target, we can generate
marine_test_envonly for tests. This is needed because our generator depends on the artifacts from
wasm32-wasibuild. We suggest using a separate crate for using build scripts for testing purposes. It is here for simplicity.
marine_test_envgenerator. Just always use
file!()for the last argument. The generated file will be in the directory specified by the
OUT_DIRvariable, which is set by cargo. The build script must not change any files outside of this directory.
marine_test_envdefinition to the project.
loggerfeature allows you to use a special logger that is based at the top of the log crate.
loggerfeature of the Fluence SDK in
Config.tomland add the log crate:
mainfunction as shown in the example below.
logging_mask, which can be set for each module in the service configuration. Let's consider an example:
TARGET_MAPis defined and provided to a logger in the
mainfunction of a module. Each entry of this array contains a string (a target) and a number that represents the bit position in the 64-bit mask
logging_mask. When you write a log message request
log::info!, its target must coincide with one of the strings (the targets) defined in the
TARGET_MAParray. The log will be printed if
logging_maskfor the module has the corresponding target bit set.
deallocatefunction calls. The
sdk.allocate: 4line corresponds to passing the 4-byte
userstring to the Wasm module, with the memory allocated inside the module and the string is copied there. Whereas
sdk.deallocate: 0x110080 8refers to passing the 8-byte resulting string
Hi, userto the host side. Since all arguments and results are passed by value,
deallocateis called to delete unnecessary memory inside the Wasm module.
module_manifest!macro embeds the Interface Type (IT), SDK and Rust project version as well as additional project and build information into Wasm module. For the macro to be usable, it needs to be imported and initialized in the main.rs file: