Make server a library, and add integration test for testing protocol crate on wasm
#517
Conversation
…ls, and add integration test
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| use subxt::ext::sp_core::{sr25519, sr25519::Signature, Pair}; | ||
|
|
||
| /// Verfiy a signature in a response from `/user/sign_tx` | ||
| pub async fn verify_signature( |
There was a problem hiding this comment.
This is copied from the user api unit tests, and should really live somewhere common. But strictly speaking, the other tests which call this are also integration tests and should be moved here. IMO that would be better than moving this function to a common crate such as testing-utis. But it is a bigger task for another PR.
| assert_eq!(response.status(), StatusCode::OK); | ||
| assert_eq!(response.text().await.unwrap(), ""); | ||
|
|
||
| let registered_info = wait_for_register_confirmation(one.to_account_id(), api, rpc).await; |
There was a problem hiding this comment.
Here i changed the test to use the on-chain RegisteredInfo rather than calling an unsafe API method - as we don't have access to the unsafe API methods here anymore.
ameba23
changed the title
server a library, and add integration test for testing protocol crate on wasm
| lazy_static::lazy_static! { | ||
| /// A shared reference to the logger used for tests. | ||
| /// | ||
| /// Since this only needs to be initialized once for the whole test suite we define it as a lazy | ||
| /// static. | ||
| pub static ref LOGGER: () = { | ||
| // We set up the tests to only print out logs of `ERROR` or higher by default, otherwise we | ||
| // fall back to the user's `RUST_LOG` settings. | ||
| tracing_subscriber::fmt() | ||
| .with_env_filter(tracing_subscriber::EnvFilter::from_default_env()) | ||
| .init(); | ||
| }; | ||
| } | ||
|
|
||
| /// Initialize the global loger used in tests. | ||
| /// | ||
| /// The logger will only be initialized once, even if this function is called multiple times. | ||
| pub fn initialize_test_logger() { | ||
| lazy_static::initialize(&LOGGER); | ||
| } |
There was a problem hiding this comment.
This is now duplicated, I imagine it's a post-merge artifact. This code also exists in helpers/tests.rs and it makes sense for us to use that code instead since the logger isn't necessarily just for the server process.
| lazy_static::lazy_static! { | |
| /// A shared reference to the logger used for tests. | |
| /// | |
| /// Since this only needs to be initialized once for the whole test suite we define it as a lazy | |
| /// static. | |
| pub static ref LOGGER: () = { | |
| // We set up the tests to only print out logs of `ERROR` or higher by default, otherwise we | |
| // fall back to the user's `RUST_LOG` settings. | |
| tracing_subscriber::fmt() | |
| .with_env_filter(tracing_subscriber::EnvFilter::from_default_env()) | |
| .init(); | |
| }; | |
| } | |
| /// Initialize the global loger used in tests. | |
| /// | |
| /// The logger will only be initialized once, even if this function is called multiple times. | |
| pub fn initialize_test_logger() { | |
| lazy_static::initialize(&LOGGER); | |
| } |
There was a problem hiding this comment.
Ah i put the other comment about this before i read this. Am i understanding right that you want initialize_test_logger to stay in src/helpers/tests? Everthing in that module is #[cfg(test)]`, so we cant use it for integration tests.
There was a problem hiding this comment.
Yeah it would be better there imo.
We may we able to initialize the logger in a nicer way from outside of a test context after #520 though. So we can wait if you want
There was a problem hiding this comment.
At first glace it's a bit confusing to have both server/helpers/test.rs and these integration test helpers. We should think a bit about how to split the test code up a bit better so it's clear why things are in one and not the other.
You do mention in your comment that right now is there is an overlap between unit tests and integration tests, so I guess this is something to work towards in the future.
There was a problem hiding this comment.
Its hard. We can't access tests/helpers from unit tests and we can't access src/helpers/tests from integration tests. testing-utils is the only place which is common to both.
For context see: #508
The idea of this was just to add a couple of integration tests, but its turned out to be much bigger than i expected because
serveris not a library crate, only a binary, so doesn't have a public api at all.This moves the helper functions for setting up our test environment to the
testing-utilscrate so we can access them from outsideserver. I think this is worth doing as we probably want other integration tests.serverhas become a library and exposes theappfunction, several things relating to 'launch', and some common functions needed on the client side for testing. If we decided we would rather not do this, we could instead run theserverbinary as a child process as we do withentropyand test it that way, and put common functions in a separate crate.This sets things up nicely for the other PR i have up to make a test client based on the code used in tests.