Writing unit tests for Rust side #328

TheTharin · 2024-05-20T09:51:40Z

TheTharin
May 20, 2024

Hi there.

I'm new to Rust ecosystem in general and to rinf in particular. I need help writing unit tests for my Rust side of the app for both receiving messages from Dart and sending messages to Dart. The actual app code works fine and manual testing of the integration shows that everything works correctly, but when I try to write tests for my integration, they keep failing for reasons not yet apparent to me.
The first problem is writing receiver tests. Please, take a look at the following example:

use crate::messages::dialogue::DialogueRequest;

pub async fn test_receiver(number: i8) {
    let mut receiver = DialogueRequest::get_dart_signal_receiver();

    println!("Test receiver number is {}", number);

    while let Some(_dart_signal) = receiver.recv().await {
        println!("Test receiver number is {}", number + 100);
    }
}

#[cfg(test)]
mod tests {
    use std::{cell::RefCell, sync::Mutex};

    use crate::messages::dialogue::DIALOGUE_REQUEST_SENDER;

    use super::*;
    use tokio_with_wasm::tokio;

    #[tokio::test]
    async fn test_receive_character_creation_change() {
        tokio::spawn(test_receiver(1));
        tokio::time::sleep(tokio::time::Duration::from_millis(10)).await;

        let binding = DIALOGUE_REQUEST_SENDER
            .get_or_init(|| Mutex::new(RefCell::new(None)))
            .lock()
            .unwrap();
        let binding = binding.borrow();
        let sender = binding.as_ref().unwrap();

        if let Ok(_result) = sender
            .send(rinf::DartSignal::<DialogueRequest> {
                message: DialogueRequest {},
                blob: None,
            })
            .await
        {
            println!("Sent dialogue request");
        }
    }
}

And here is what is in the cargo test results:

successes:

---- receivers::test_receiver::tests::test_receive_character_creation_change stdout ----
Test receiver number is 1
Sent dialogue request

As you can see, the sender send method returns an Ok tuple, but it looks like it's either sending it to a wrong channel, or receiver is not receiving the message, as there is no Test receiver number is 101 print in stdout. I assume there could be a problem in the way I'm borrowing the DIALOGUE_REQUEST_SENDER, but it looks as if it is valid to call send on, and I'm not cloning it, so it should be the very same DIALOGUE_REQUEST_SENDER from the code-generated dialogue message.
I'm not sure, what is actually happening here, I humbly ask your for advice, or a test example would be even better.

The second problem is sending messages from Rust side:

use crate::messages::{dialogue::DialogueRequest, scene::CurrentSceneChange};

pub async fn test_sender() {
    CurrentSceneChange { scene: 0 }.send_signal_to_dart(None);
}

#[cfg(test)]
mod tests {
    use super::*;
    use tokio_with_wasm::tokio;

    #[tokio::test]
    async fn test_test_sender() {
        test_sender().await;
    }
}

This test panics with this stack trace:

---- receivers::test_receiver::tests::test_test_sender stdout ----
thread 'receivers::test_receiver::tests::test_test_sender' panicked at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rinf-6.7.0/src/interface_os.rs:30:35:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0: rust_begin_unwind
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panicking.rs:647:5
   1: core::panicking::panic_fmt
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/panicking.rs:72:14
   2: core::panicking::panic
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/panicking.rs:144:5
   3: core::option::unwrap_failed
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/option.rs:1978:5
   4: core::option::Option<T>::unwrap
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/option.rs:931:21
   5: rinf::interface_os::send_rust_signal_extern
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rinf-6.7.0/src/interface_os.rs:30:16
   6: rinf::interface::send_rust_signal
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rinf-6.7.0/src/interface.rs:24:5
   7: hub::messages::scene::CurrentSceneChange::send_signal_to_dart
             at ./src/messages/scene.rs:95:9
   8: hub::receivers::test_receiver::test_sender::{{closure}}
             at ./src/receivers/test_receiver.rs:14:5
   9: hub::receivers::test_receiver::tests::test_test_sender::{{closure}}
             at ./src/receivers/test_receiver.rs:51:23
  10: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/future/future.rs:124:9
  11: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/future/future.rs:124:9
  12: tokio::runtime::scheduler::current_thread::CoreGuard::block_on::{{closure}}::{{closure}}::{{closure}}
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/scheduler/current_thread/mod.rs:659:57
  13: tokio::runtime::coop::with_budget
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/coop.rs:107:5
  14: tokio::runtime::coop::budget
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/coop.rs:73:5
  15: tokio::runtime::scheduler::current_thread::CoreGuard::block_on::{{closure}}::{{closure}}
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/scheduler/current_thread/mod.rs:659:25
  16: tokio::runtime::scheduler::current_thread::Context::enter
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/scheduler/current_thread/mod.rs:404:19
  17: tokio::runtime::scheduler::current_thread::CoreGuard::block_on::{{closure}}
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/scheduler/current_thread/mod.rs:658:36
  18: tokio::runtime::scheduler::current_thread::CoreGuard::enter::{{closure}}
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/scheduler/current_thread/mod.rs:737:68
  19: tokio::runtime::context::scoped::Scoped<T>::set
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/context/scoped.rs:40:9
  20: tokio::runtime::context::set_scheduler::{{closure}}
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/context.rs:176:26
  21: std::thread::local::LocalKey<T>::try_with
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/thread/local.rs:286:16
  22: std::thread::local::LocalKey<T>::with
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/thread/local.rs:262:9
  23: tokio::runtime::context::set_scheduler
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/context.rs:176:9
  24: tokio::runtime::scheduler::current_thread::CoreGuard::enter
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/scheduler/current_thread/mod.rs:737:27
  25: tokio::runtime::scheduler::current_thread::CoreGuard::block_on
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/scheduler/current_thread/mod.rs:646:19
  26: tokio::runtime::scheduler::current_thread::CurrentThread::block_on::{{closure}}
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/scheduler/current_thread/mod.rs:175:28
  27: tokio::runtime::context::runtime::enter_runtime
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/context/runtime.rs:65:16
  28: tokio::runtime::scheduler::current_thread::CurrentThread::block_on
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/scheduler/current_thread/mod.rs:167:9
  29: tokio::runtime::runtime::Runtime::block_on
             at /Users/tharin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/runtime.rs:349:47
  30: hub::receivers::test_receiver::tests::test_test_sender
             at ./src/receivers/test_receiver.rs:51:9
  31: hub::receivers::test_receiver::tests::test_test_sender::{{closure}}
             at ./src/receivers/test_receiver.rs:50:32
  32: core::ops::function::FnOnce::call_once
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/ops/function.rs:250:5
  33: core::ops::function::FnOnce::call_once
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

As you can see from the line 5 of the stacktrace, rinf::interface_os::send_rust_signal_extern panicked while trying to unwrap DART_ISOLATE.get().unwrap().lock().unwrap() .
It looks as if I have to perform a setup of sorts for my tests, and both of the problems are somehow related to each other, but as I'm fairly new to debugging Rust code, I'm not sure how. I hope you could help me with that.

Thanks in advance!

Answered by temeddix

May 20, 2024

Hi @TheTharin :)

For the first problem, I suggest you to sleep for some time after sending the signal so that tokio runtime and its event loop can keep alive for some more time, allowing the receiver to receive the signal.

use crate::messages::dialogue::DialogueRequest;

pub async fn test_receiver(number: i8) {
    let mut receiver = DialogueRequest::get_dart_signal_receiver();

    println!("Test receiver number is {}", number);

    while let Some(_dart_signal) = receiver.recv().await {
        println!("Test receiver number is {}", number + 100);
    }
}

#[cfg(test)]
mod tests {
    use std::{cell::RefCell, sync::Mutex};

    use crate::messages::dialogue::DIALOGUE_REQUEST_SENDER;

    …

View full answer

temeddix · 2024-05-20T10:56:07Z

temeddix
May 20, 2024
Maintainer

Hi @TheTharin :)

For the first problem, I suggest you to sleep for some time after sending the signal so that tokio runtime and its event loop can keep alive for some more time, allowing the receiver to receive the signal.

use crate::messages::dialogue::DialogueRequest;

pub async fn test_receiver(number: i8) {
    let mut receiver = DialogueRequest::get_dart_signal_receiver();

    println!("Test receiver number is {}", number);

    while let Some(_dart_signal) = receiver.recv().await {
        println!("Test receiver number is {}", number + 100);
    }
}

#[cfg(test)]
mod tests {
    use std::{cell::RefCell, sync::Mutex};

    use crate::messages::dialogue::DIALOGUE_REQUEST_SENDER;

    use super::*;
    use tokio_with_wasm::tokio;

    #[tokio::test]
    async fn test_receive_character_creation_change() {
        tokio::spawn(test_receiver(1));
        tokio::time::sleep(tokio::time::Duration::from_millis(10)).await;

        let binding = DIALOGUE_REQUEST_SENDER
            .get_or_init(|| Mutex::new(RefCell::new(None)))
            .lock()
            .unwrap();
        let binding = binding.borrow();
        let sender = binding.as_ref().unwrap();

        if let Ok(_result) = sender
            .send(rinf::DartSignal::<DialogueRequest> {
                message: DialogueRequest {},
                blob: None,
            })
            .await
        {
            println!("Sent dialogue request");
        }
        tokio::time::sleep(Duration::from_millis(100)).await;  // <<<<<<<< ADD THIS LINE
    }
}

For the second problem, you need to call prepare_isolate_extern via C extern function to prepare DART_ISOLATE. Try writing your code like below. I'm not sure if this would work because Dart runtime wouldn't exist in test code written in Rust. I haven't tested this myself, so please share your results if you can!

extern "C" {
    fn prepare_isolate_extern(port: i64);
}

unsafe {
    prepare_isolate_extern(42);
}

5 replies

TheTharin May 20, 2024
Author

Thank you very much. Everything you suggested helped and now my tests are not panicking or failing.
Now I have a follow-up question:
Can you give me an advice on how to test that my test_receiver function has actually called CurrentSceneChange { scene: 0 }.send_signal_to_dart(None); ? Maybe there is something I can assert against?

temeddix May 20, 2024
Maintainer

Not that I'm aware of. I'm not really sure if you can simulate the Dart runtime in Rust. I am sorry that I can't be of help here.

TheTharin May 20, 2024
Author

I see. Well, then I'll keep looking. Thanks again for clarifications!

rj76 Dec 7, 2024

Hey @TheTharin, I was curious if you were able to figure this out :) At first I was thinking writing flutter tests against the exposed rust functionality, but that would also mean to get the rust code into some kind of test environment and I'm not sure it works like that.

TheTharin Dec 7, 2024
Author

Hi, @rj76

Saddly, I stopped looking into rinf pretty soon after this topic and switched to writing my game with a different toolset.
I haven't found an answer to that question, I'm sorry.
Hope you find a suitable way to test the receivers.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Writing unit tests for Rust side #328

{{title}}

Replies: 1 comment 5 replies

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Writing unit tests for Rust side #328

TheTharin May 20, 2024

Replies: 1 comment · 5 replies

temeddix May 20, 2024 Maintainer

TheTharin May 20, 2024 Author

temeddix May 20, 2024 Maintainer

TheTharin May 20, 2024 Author

rj76 Dec 7, 2024

TheTharin Dec 7, 2024 Author

TheTharin
May 20, 2024

Replies: 1 comment 5 replies

temeddix
May 20, 2024
Maintainer

TheTharin May 20, 2024
Author

temeddix May 20, 2024
Maintainer

TheTharin May 20, 2024
Author

TheTharin Dec 7, 2024
Author