-
I have a regular Actor. It specifies a vocabulary, which is an
The handler loop is quite ordinary too:
My test driver is structured this way:
use ractor::Actor;
use ractor::call_t;
use crate::elevator_service::ElevatorVocabulary;
use super::ElevatorInstallation;
#[tokio::test]
async fn when_powered_on_elev_should_goto_ground_floor() -> () {
let (actor_ref, actor_handle) =
Actor::spawn(
Some(String::from("Elevator-Actor")),
ElevatorInstallation,
0
).await
.expect("Failed to start actor");
// The following line fails to compile!
let resp1 = call_t!(actor_ref,ElevatorVocabulary::PowerOn(None),1).unwrap(); // Problem!
assert_eq!(
match resp1 {
ElevatorVocabulary::MoveToFloor(0,_) => true,
_ => false
},
true
);
} The compiler says (screenshot): It seems to me that I am missing something crucial about I have been following the documentation of In case the context helps, my intention is to draw a pattern of 'testing' Actors, much in the line of Akka's TestActor. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
You shouldnt be sending an actor handle as the reply, this is what If you look at the source code for the crate, the tests for the rpc module should show you how the usage is expected to be defined. Additionally your test comparison would be a bit easier to reason about with |
Beta Was this translation helpful? Give feedback.
You shouldnt be sending an actor handle as the reply, this is what
RpcReplyPort
is specifically for. It's a channel to receive the reply of a defined message type. It's what all the call macros are expecting as the last argument of the tuple includingActorRef.call
.If you look at the source code for the crate, the tests for the rpc module should show you how the usage is expected to be defined.
Additionally your test comparison would be a bit easier to reason about with
assert!(matches!(ExpectedPattern, result))