Cleanup tests related to transition and finalizer_policy updates. #108
Conversation
Should not be 3 if we have 3 finalizers.
…change in `threshold` computation.
… trace. See issue #88.
|
Note:start |
| uint16_t confirm_block_count, | ||
| const vector<digest_type>& new_protocol_feature_activations, | ||
| block_status bs, | ||
| const fc::time_point& deadline = fc::time_point::maximum() ); |
There was a problem hiding this comment.
Instead of modifying controller, seems like the tester should connect to applied_transaction which would include the onblock.
There was a problem hiding this comment.
What is the drawback of having start_block returning the trace?
push_transaction does return the trace and the same reasoning could apply.
There was a problem hiding this comment.
Using the applied_transaction signal tests that the signal is called appropriately, would be nice to have some tests around that functionality. I don't have a strong rejection to having start_block return the onblock trace.
There was a problem hiding this comment.
Since we already get the transaction traces in libtester as a result of control->push_transaction(), I'd rather leave as-is.
I think it seems appropriate for start_block to return the onblock trace.
|
Note:start |
…hen more nodes are configured.
Resolves #88, #47
base_testerwhich returns the transaction traces (including foronblock) in addition to thesigned_block_ptrbase_testerto validate finalizer policy changes (check_head_finalizer_policy).finalizer_keysclass intester.hppwhich can be used to manage finalizer keys forfinalizer_policies, as well as provide APIs forset_node_finalizers,set_finalizer_policyandtransition_to_savanna.libinbase_tester, so that the connection to theirreversible_blocksignal doesn't have to be repeated in multiple tests.finality_test_clusterto having a configurable number of nodes (4 or more), use newtester.hppfeatures, fix multiple issues in tests.api_tests.cpp,finalizer_update_tests.cpp, etc... ) to use these new facilities and avoid duplication.