:red_circle: All new Golos blockchain versions should be tested and there are few categories of tests that should be made and successfully passed before release:
API tests -- they're used to check all API methods correct work.
Regression testing -- these tests check that new features do not break current functionality
Integration testing -- such tests are needed to test new features correct work
:red_circle: Btw, Regression and Integration tests can be splited on two groups:
First one can be isolated from daemon and send API commands to it to complete test.
Second one needs test daemon's work with some specified config parameters and thats why such tests need to do hypervisor's work.
There are much more tests from first group and they can be easily dockerized and runned with side working golosd wtih docker compose after. Thats is a pretty solution which guarantee that the release vesion is clean, nothing was changed in code and tests use just its functionality and are not changing the product.
The second group is more complicated, because such tests need to run daemon with different configurations to test parameters work for instance.
:red_circle: Thats why I decided to split tests to three folders for now:
API tests (unit tests for API methods)
Tests wich use multiple API methods
Tests with hypervisor's work
Development plan for now
I can assume that MVP is ready when following points are done:
[x] :gear: Write confugurator
[x] :file_folder: Separate api_tests and config_tests
[x] :hammer_and_pick: Write one API test
[x] :hammer_and_wrench: Write one Hypervisior test
[x] :whale: Write configurable docker container runner for api_tests
[x] :whale2: Write tools for work with docker container and filesystem with JS code
Optional :wrench: Rewrite asserts with tools for testing Mocha and Chai
Description
:red_circle: All new Golos blockchain versions should be tested and there are few categories of tests that should be made and successfully passed before release:
:red_circle: Btw, Regression and Integration tests can be splited on two groups:
There are much more tests from first group and they can be easily dockerized and runned with side working golosd wtih docker compose after. Thats is a pretty solution which guarantee that the release vesion is clean, nothing was changed in code and tests use just its functionality and are not changing the product.
The second group is more complicated, because such tests need to run daemon with different configurations to test parameters work for instance.
:red_circle: Thats why I decided to split tests to three folders for now:
Development plan for now
I can assume that MVP is ready when following points are done:
api_tests
andconfig_tests