bitshares / bitshares/bitshares-core
Regression test for each hard fork
- Dominant language
- C++
- Stars
- 1.2k
- Forks
- 660
- Avg merge
- 8h 17m
- Merged PRs (30d)
- 26
Description
By now, in many tests, there is code to proceed to the hard fork times that enabled the features, so essentially we do check whether the tests pass just after the hard forks occur, but do not check if they still pass after a longer time.
E.G. in the `htlc_expires` test, there is code https://github.com/bitshares/bitshares-core/blob/c06d09cecdd9e7526a23456986eb2f9b2b6894aa/tests/tests/htlc_tests.cpp#L83
Ideally we should run tests which still apply after each hard fork.
E.G. for the `htlc_expires` test, ideally we should test with
```
Test {
advance_past_htlc_first_hardfork();
INVOKE(htlc_expires_test);
}
Test_next {
advance_past_the_next_hardfork();
INVOKE(htlc_expires_test);
}
Test_next_next {
advance_past_next_next_hardfork();
INVOKE(htlc_expires_test);
}
// more hard forks and more tests ...
```
An idea is to generate code with CMake script to proceed to each hard fork time and invoke applicable tests.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with tests/tests/htlc_tests.cpp, especially the htlc_expires test and its existing hard-fork advancement code. Review how hard-fork times and applicable tests are represented, then determine how each test should be invoked after later forks. Done means regression tests run for applicable tests after each hard fork, including the htlc_expires case.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- blockchain, cmake, cpp
- Domain
- blockchain, testing-qa
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100