Include simple CLI with testing-utils #417
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>
Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>
…o subxt-client * 'subxt-client' of github.com:entropyxyz/entropy-core: Initialize test logger in integration test Initialise test logger in integration test
|
@HCastano i think i have made all the changes you suggested.
I've added a readme with as many gotchas as i can think of. If it still doesn't seem to work, please let me know. |
| async fn integration_test_sign() { | ||
| clean_tests(); |
There was a problem hiding this comment.
Hmm fair enough. Alright let's leave the logging out for now then and maybe follow up with it in another PR/issue
Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>
Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>
…features of sp-core
| @@ -9,6 +9,8 @@ At the moment this project **does not** adhere to | |||
|
|
|||
| ## [Unreleased] | |||
|
|
|||
| - Test CLI which calls the same code as in integration tests ([#417](https://github.com/entropyxyz/entropy-core/pull/417)) | |||
There was a problem hiding this comment.
@ameba23 the CHANGELOG entry should match the PR title. We also need to put this under a header, e.g Added, Changed, etc.
Thanks for remembering to add an entry to the CHANGELOG though 😄
This adds a simple client to the
testing-utilscrate, which allows us to register, update a program, and sign a message, and an integration test which uses it.The idea is to have a simple client which is tested as part of CI. So when making a deployment you can check things are working with a client which is likely to work as long as CI passes.
For the CLI, there is no private key storage, rather you give an 'account name' used as a seed string, so if you give the name 'foo' you get the same keypair that
subkey inspect //foowould give you.Unfortunately, its not currently possible to test registering. Since our testing setup only has one chain node running, only one of the TSS server gets info from the propagation pallet. In unit tests we 'simulate' the second chain node making requests to the second TSS server, but thats harder to do in an integration test. I am gonna make an issue for this, but for now i've tested registering manually using the CLI with both the AWS devnet and locally with docker compose.