add tests for unstable_backend #1765
Conversation
| } | ||
|
|
||
| impl Data { | ||
| async fn call_meth<'a>( |
There was a problem hiding this comment.
| async fn call_meth<'a>( | |
| async fn call<'a>( |
| (*method)(&mut self.data_table, &mut self.subscription_channel, params) | ||
| } | ||
|
|
||
| async fn call_subscription<'a>( |
There was a problem hiding this comment.
| async fn call_subscription<'a>( | |
| async fn subscribe<'a>( |
|
|
||
| type RpcResult<T> = Result<T, RpcError>; | ||
| type Item = RpcResult<String>; | ||
| pub type SubscriptionHandler = Box< |
There was a problem hiding this comment.
quite complicated type and a bit hard to read but I'm fine to remove the lifetimes and cloning the data for each call if it simplifies the code...
it just tests anyway
|
|
||
| struct MockDataTable { | ||
| items: HashMap<Vec<u8>, VecDeque<Item>>, | ||
| pub enum Message<T> { |
There was a problem hiding this comment.
dq: why is many Result<T, Error> and a single just T?
| request: MockDataTable, | ||
| subscription: Subscription, | ||
| data_table: MockDataTable, | ||
| subscription_channel: Option<Subscription>, |
There was a problem hiding this comment.
can you move the subscription_channel to the subscription handler? or is this needed to keep the channel alive?
| } | ||
| Message::Single(item) => sender.send(item).await.unwrap(), | ||
| }; | ||
| }); | ||
| } | ||
| } | ||
|
|
||
| struct Data { |
There was a problem hiding this comment.
I find it a bit of strange call this type Data which has functionality to perform rpc calls and subscription + the mock data table.
I would rather remove this struct and move all this functionality to the MockedRpcClient or rename this to InnerMockedRpcClient or something like that
| Self { | ||
| data: Data { | ||
| data_table: MockDataTable::new(), | ||
| subscription_channel: None, |
There was a problem hiding this comment.
is this always None? can we remove it?
| } | ||
| } | ||
|
|
||
| pub fn add_method(mut self, method_name: &str, meth: MethodHandler) -> Self { |
| .add_mock_data_from_iter(response_data) | ||
| .build(); | ||
|
|
||
| let (backend, mut driver): (UnstableBackend<Conf>, _) = |
There was a problem hiding this comment.
move this unstable backend stuff to a helper function such as fn run_backend? It's used for several tests
| Ok(resp1 @ StorageResponse { .. }), | ||
| Ok(resp2 @ StorageResponse { .. }), | ||
| Err(Error::Other(s)) | ||
| ] if s == "errro" |
There was a problem hiding this comment.
typo?
| ] if s == "errro" | |
| ] if s == "error" |
|
|
||
| assert!(matches!( | ||
| response, | ||
| Err(Error::Other(reason)) if reason == "errro" |
There was a problem hiding this comment.
typo?
| Err(Error::Other(reason)) if reason == "errro" | |
| Err(Error::Other(reason)) if reason == "error" |
| self | ||
| } | ||
|
|
||
| pub fn add_mock_data_from_iter< |
There was a problem hiding this comment.
since this is the only way to add mock_data, why not removing the from_iter?
| pub fn add_mock_data_from_iter< | |
| pub fn add_mock_data< |
| @@ -839,6 +874,22 @@ pub(crate) mod hashmap_as_tuple_list { | |||
| deserializer.deserialize_any(HashMapVisitor(PhantomData)) | |||
| } | |||
|
|
|||
| /// Serialize a number as string | |||
There was a problem hiding this comment.
I wonder rather move these helpers to the test module
| @@ -778,6 +799,9 @@ pub(crate) mod unsigned_number_as_string { | |||
| use serde::de::{Deserializer, Visitor}; | |||
| use std::fmt; | |||
|
|
|||
| #[cfg(test)] | |||
| use serde::ser::Serializer; | |||
| @@ -786,6 +810,14 @@ pub(crate) mod unsigned_number_as_string { | |||
| deserializer.deserialize_any(NumberVisitor(std::marker::PhantomData)) | |||
| } | |||
|
|
|||
| /// Serialize a number as string | |||
Description
As in the title. This PR adds tests for
UnstableBackendimplementation in subxt/backend.The tests are mostly about testing
StorageResponsesin different cases of reconnections.Pr uses a mocked
RpcClientimplementation for providing expected responses.Additional changes
MockRpcClientto be usable across legacy backend and unstable_backend following suggestion from last PRPart of the work on #1677