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

Create PR on Prototype feedback #64

Open
tesnimab opened this issue Jul 27, 2022 · 0 comments
Open

Create PR on Prototype feedback #64

tesnimab opened this issue Jul 27, 2022 · 0 comments
Assignees

Comments

@tesnimab
Copy link

tesnimab commented Jul 27, 2022

Here are some preliminary feedbacks regarding the Atomkraft prototype.



Given that our focus is to build an e2e testing framework for cosmos SDK projects, there are ways to be more specific on certain points that would ease the usage and maybe developments.
We can first think in terms of module testing so the first thing to provide is a reactor per module:

  • A module has an “API” that defines transaction calls with parameters that are used in test suits to be run over testnets. Thus, we can have a reactor per module that constructs generic transaction calls in python.
  • A trace expresses a certain logic of transaction calls with specific parameters. Thus, the data structure in the trace should be aligned with reactor function calls/variables. Traces are constrained by reactors so we are not writing reactors to fit the trace witch is a change in the logic described in ADRs. This also constrains the model (maybe we can provide model templates, types, and variables)
  • Future points to evaluate: modules interconnections
  • The set-up creates a pytest project with necessary configurations and a project structure. It has been thought as if we are going to instantiate Atomkraft for each module separately but maybe we will have one instance dealing with all modules. (To be confirmed).
  • It is also more convenient to understand where the tests come from (traces and models) so putting them together under the same directory is better than having all the models in a repo, and all the traces in another without understanding the links between them. (Same for reactors)
  • In the initialization, it is also good to provide a testnet configuration in place (I have to play with the prototype)
  • It is important to transport the work done on the authz module to figure things out.

So from this project structure:
+- .atomkraft/
+- models/
+- traces/
+- reactors/
+- tests
| +- test_authz.py
| +- test_gov.py
+- reports/
+- testnet
| +- config
| | +- app.toml
| | +- config.toml
| | +- genesis.json
| +- run
| +- validator-1/
| +- validator-2/
| +- validator-3/
+- pyproject.toml

We would maybe have this:

+- .atomkraft/
+- modules/
| +- authz
|
| | +- reactors/
| | +- tests/
| | | +- models/
| | | +- traces/
| | | +- tests/
| | | | +- test_authz.py
| | +- reports/ (Scripts ?)
| +- gov
|
| | +- reactors/
| | +- tests/
| | | +- models/
| | | +- traces/
| | | +- tests/
| | | | +- test_gov.py
| | +- reports/ (Scripts ?)

And a single testnet :
+- testnet
| +- config
| | +- app.toml
| | +- config.toml
| | +- genesis.json
| +- run
| +- validator-1/
| +- validator-2/
| +- validator-3/
+- pyproject.toml

@tesnimab tesnimab added this to the Atomkraft prototype milestone Jul 27, 2022
@andrey-kuprianov andrey-kuprianov changed the title Prototype feedback Create PR on Prototype feedback Aug 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants