Project: Fluvio (App Definition and Development / Streaming & Messaging)
File: README.md

Used to run a various test against `Fluvio` platform. This assumes you have read Fluvio doc and setup or access to a Fluvio cluster . Build all `Fluvio` crates Build development kubernetes image Must run test runner from fluvio repo root (issue: #) ``` make build-test make buildk8image ``` (More about ) By default we test with debug compiler symbols with the `development` profile. Optional: Set up alias to run development version of Fluvio and Test runner CLI. ``` cargo build alias fluvio-test=./target/debug/fluvio-test ``` It's important to test Fluvio's release artifact (without the debug symbols) in order to reproduce the same behavior as in production. This is as easy as adding `--release` to the `cargo build` command. Optional: Set up alias to run release version of Fluvio and Test runner CLI. ``` cargo build --release alias fluvio-test=./target/release/fluvio-test ``` ``` fluvio-test <test-name> [FLAGS] [OPTIONS] -- [SUBCOMMAND OPTIONS] ``` Test runner testing doesn't work when VERSION set to an unpublished version. Workaround: Run `make buildk8image` and use `--develop` flag with `fluvio-test` (issue #) Test runner can be a running in two ways: Create new cluster (local or k8) and run test Run tests against existing cluster Expected behavior of local clusters that fluvio-test start: If you `ctrl+c`, the local cluster will also be terminated. If you want to deploy a cluster before or delete your cluster after a test, then pass `--cluster-start` or `--cluster-delete` flags, respectively. The `--cluster-start-fresh` flag will delete, then re-start a cluster before the test begins The smoke test can be configured with it's own CLI options: `fluvio-test smoke [environment vars] -- [smoke test vars]` This is an example of running a simple test, the smoke test. creating new local cluster It creates a simple topic: `topic` and perform produce/consume ``` $ fluvio-test smoke --cluster-start --cluster-delete Start running fluvio test runner Starting cluster and testing connection remove cluster skipped installing cluster Installing Fluvio Fluvio app chart has been installed Found SC service addr: 172.18.0.2:32309 Profile set SPU group launched (1) All SPUs confirmed Successfully installed Fluvio! Creating the topic: test topic "test" created found topic: test offset: 0 starting fetch stream for: test base offset: 0, expected new records: 1 found topic: test offset: 0 total records sent: 0 chunk time: 0.0 secs consume message validated!, records: 1 replication status verified performing 2nd fetch

waiting 5 seconds performing complete fetch stream for: test base offset: 0, expected new records: 1 full <<consume test done for: test >>>> deleting cluster +--+--+ | Test Results | | +--+--+ | Pass? | true | +--+--+ | Duration | 5.028603585s | +--+--+ ``` Smoke test can be specified with more than 1 iterations: Run a test with sending 10 records: ``` $ fluvio-test smoke --local -- --producer-iteration 10 ``` ``` $ fluvio-test smoke --local -- --producer-iteration 10 $ fluvio-test smoke -- --producer-iteration 200 ``` By default, produce and consumer run in parallel, but you can force consumer to wait for all producer iteration ``` $ fluvio-test smoke -- --producer-iteration=400 --consumer-wait ``` There are 2 parts to adding new tests. Creating a new test in the `tests` module + annotating with `#[fluvio_test]` Add `#[derive(MyTestCase)]` to test struct (for CLI options) Your test needs to create a struct to hold test-specific variables. (This is required, even if it is empty.) The struct should derive `Parser`. The test runner uses this struct in order to parse cli flags for your test with Write new tests in the `tests` module of the `fluvio-test` crate. Here's a complete stub to modify: ```rust use std::env; use clap::Parser; use fluviotestderive::fluvio_test; use fluviotestcase_derive::MyTestCase; pub struct ExampleOption { pub verbose: bool, } pub fn example(mut testdriver: FluvioTestDriver, mut testcase: TestCase) { let exampletestcase: MyTestCase = test_case.into(); [...] } ``` `TestCase` has an internal field `option` that is `Box<dyn TestOption>`. You'll want to implement `From<TestCase>` on your own struct so you can downcast and use this struct more flexibly. See `tests/smoke/mod.rs` or `tests/concurrent/mod.rs` for more example boilerplate code The `#[fluvio_test]` macro will expand your test to create a topic and check if the `TestCase` meets your test requirements. Test requirements can be defined by using the following variables with the macro: `min_spu` -- default value is `1` if unset Setting a default topic name can be defined by setting the following with the macro: `topic` -- default value: `topic` if unset example: Set both `min_spu` and `topic` on test. ```rust pub fn run(client: Arc<Fluvio>, mut option: TestCase) { println!("Hello world!") } ``` (For `async/await` test code, use the `async` attribute with the macro) ```rust pub async fn run(client: Arc<Fluvio>, mut option: TestCase) { println!("Hello world!") } ``` If this test's name was `example`, we can start this test by running: `cargo run --bin fluvio-test -- example` Which would be skipped, because the test requires 2 spu, and by default we only have one. But if we run it like: `cargo run --bin fluvio-test -- example --spu 2` The test would start and a test topic named `test_topic` would be created because the minimum requirements were met.