Denis Pisarev
fc253e6e4d
* CI: add spellcheck * revert me * CI: explicit command for spellchecker * spellcheck: edit misspells * CI: run spellcheck on diff * spellcheck: edits * spellcheck: edit misspells * spellcheck: add rules * spellcheck: mv configs * spellcheck: more edits * spellcheck: chore * spellcheck: one more thing * spellcheck: and another one * spellcheck: seems like it doesn't get to an end * spellcheck: new words after rebase * spellcheck: new words appearing out of nowhere * chore * review edits * more review edits * more edits * wonky behavior * wonky behavior 2 * wonky behavior 3 * change git behavior * spellcheck: another bunch of new edits * spellcheck: new words are koming out of nowhere * CI: finding the master * CI: fetching master implicitly * CI: undebug * new errors * a bunch of new edits * and some more * Update node/core/approval-voting/src/approval_db/v1/mod.rs Co-authored-by: Andronik Ordian <write@reusable.software> * Update xcm/xcm-executor/src/assets.rs Co-authored-by: Andronik Ordian <write@reusable.software> * Apply suggestions from code review Co-authored-by: Andronik Ordian <write@reusable.software> * Suggestions from the code review * CI: scan only changed files Co-authored-by: Andronik Ordian <write@reusable.software>
Simulation tests, or high level integration tests
The content of this directory is meant to be used by Parity's private CI/CD infrastructure with private tools. At the moment those tools are still early stage of development and we don't know if / when they will available for public use.
Contents of this directory
configs directory contains config files in toml format that describe how to
configure the simulation network that you want to launch.
tests directory contains Cucumber files. Those are
Behavior-Driven Development test files that describe tests in plain English.
Under the hood there are assertions that specific metrics should have specific
values.
At the moment we have only one test for parachains: /parachains.features
This test uses a JS script that we added to Simnet image and it's launched
by this step in the cucumber file:
Then launch 'node' with parameters '--unhandled-rejections=strict /usr/local/bin/simnet_scripts test_parachain ./configs/adder.json ws://localhost:11222 100 10'
run_test.sh is an entry point for running all tests in the folder.
Any setup required for tests (but cannot be done in configs) is performed
here. The main script's responsibility is to run Gurke
with passed parameters.
In order to use this script locally, you need to install
Gurke
Once you have access to a kubernetes cluster (meaning you can do kubectl get pods)
you can run this script with no arguments, like ./run_test.sh and tests should run.
Kubernetes cluster can be local, spawned with
kind
or an instance living in the
cloud