It would be good practice to have CI tests that are gating PRs, and also to guarantee the state of the project main branch.
This card is about creating the smoke test suite for the project, which will be run by the Github action runner to gate changes.
The Smoke tests shouldn't be "big" but just leverage a very restricted set of the functionalities to avoid breaking the project in obvious ways. It can touch as well all the features, but it shouldn't deep dive to try to exercise total coverage of the project.
Ideally smoke tests should run in 5-10m, and be unit or functional tests covering parts of the functionalities.
This ticket is to have a small smoke test suite leveraging the basic aspects of the node (configuration, startup).
Acceptance criteria
[ ] we have a github workflow that runs on PR, main branch and releases which exercise the code. The test suite is named "smoke test"
[ ] the smoke test will exercise for now very basic checks, for instance configuration of the node, starting the oracle node and the API server and see if basic routes (e.g. the swagger API) runs correctly.
It would be good practice to have CI tests that are gating PRs, and also to guarantee the state of the project main branch.
This card is about creating the smoke test suite for the project, which will be run by the Github action runner to gate changes.
The Smoke tests shouldn't be "big" but just leverage a very restricted set of the functionalities to avoid breaking the project in obvious ways. It can touch as well all the features, but it shouldn't deep dive to try to exercise total coverage of the project.
Ideally smoke tests should run in 5-10m, and be unit or functional tests covering parts of the functionalities.
This ticket is to have a small smoke test suite leveraging the basic aspects of the node (configuration, startup).
Acceptance criteria