Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem: there are duplicated hard coded informations in integration tests #10

Closed
yihuang opened this issue Aug 16, 2021 · 4 comments · Fixed by #233
Closed

Problem: there are duplicated hard coded informations in integration tests #10

yihuang opened this issue Aug 16, 2021 · 4 comments · Fixed by #233
Assignees
Labels
good first issue Good for newcomers help wanted Extra attention is needed tests This issue is related to unit or integration tests

Comments

@yihuang
Copy link
Collaborator

yihuang commented Aug 16, 2021

follow up on: #8

The genesis keys and addresses are duplicated and hard coded in different places, better to keep them in single place for easier maintenance in the future.

@tomtau tomtau added good first issue Good for newcomers help wanted Extra attention is needed tests This issue is related to unit or integration tests labels Oct 28, 2021
@damoncro
Copy link
Contributor

I'll look into this one.

@damoncro damoncro self-assigned this Nov 23, 2021
@damoncro
Copy link
Contributor

damoncro commented Nov 24, 2021

I think this issue could be done by simple way or complicated way. There are some possible outcomes that I can think of:

  1. For easy maintenance. keys and address are duplicated in my files, in scripts, python files, yaml files, toml etc. The most important thing I guess is consolidating all the keys and addresses into one file (maybe just simply called keys.yaml or keys.toml or .env.
  2. For safety. Provide a way to control the keys generations. Maybe a test to scan all files, if keys appear in non-whitelist files, should fail the test.
  3. Complicated: For even more safety. May use keystore, gpg, or use another test framework - e.g. brownie, which I guess can provide a good key management solution, and more robust smart contract tests. I tested brownie on cronos before, it works great.

and more.

@yihuang @tomtau Free free to input your ideas, so that I can pick up the right way to do.

@yihuang
Copy link
Collaborator Author

yihuang commented Nov 24, 2021

Since it's only for testing, I think the simpler the better.
For the key management tool, there's also ethsign which comes with the dapp package, similar to brownie? but they don't work with cosmos cli I guess?

@damoncro
Copy link
Contributor

I think so, would work on the simple way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed tests This issue is related to unit or integration tests
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants