Test Epoch3.4 and Clarity5#6912
Test Epoch3.4 and Clarity5#6912BowTiedRadone wants to merge 30 commits intostacks-network:developfrom
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #6912 +/- ##
============================================
- Coverage 77.73% 61.00% -16.74%
============================================
Files 412 412
Lines 218667 218667
Branches 338 338
============================================
- Hits 169981 133387 -36594
- Misses 48686 85280 +36594 see 295 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
BowTiedRadone
force-pushed
the
test/epoch34-clarity5
branch
2 times, most recently
from
ec722ea to
7b53b4f
Compare
Eight proptests covering the version-dependent hashing change. Validates primitive/VM agreement on accept and reject paths, confirms ClarityVersion governs hashing (not epoch), and fuzzes arbitrary inputs for crash resistance.
…proptests Three new property-based tests for Clarity5 consensus deserialization: - Round-trip: serialize then from-consensus-buff? recovers original value - Type mismatch: wrong top-level constructors always returns none - Truncation: slicing a valid encoding at any interior byte returns none
BowTiedRadone
force-pushed
the
test/epoch34-clarity5
branch
from
7b53b4f to
ccc98ca
Compare
BowTiedRadone
force-pushed
the
test/epoch34-clarity5
branch
from
ccc98ca to
a02f406
Compare
BowTiedRadone
force-pushed
the
test/epoch34-clarity5
branch
from
b51347c to
2c24755
Compare
BowTiedRadone
changed the title
| let call_stack_limit = if state.chain_epoch() >= StacksEpochId::Epoch34 { | ||
| 128 | ||
| } else { | ||
| 64 | ||
| }; | ||
| let parser_limit = call_stack_limit + AST_DEPTH_BUFFER; |
There was a problem hiding this comment.
Could we leverage StackDepthLimits::for_epoch here? Then we could drop all the constants: 64, 128 and AST_DEPTH_BUFFER.
Or is the goal to replicate the stack depth computation to guard against changes in the underlying implementation? (and in this case we could just write some unit tests specifics for StackDepthLimits)
There was a problem hiding this comment.
It's the latter: the goal is to replicate the computation and guard against silent changes in the underlying implementation. If max_call_stack_depth_for_epoch or AST_CALL_STACK_DEPTH_BUFFER were accidentally modified, tests that delegate to StackDepthLimits::for_epoch would be tautological (testing the implementation against itself). The hardcoded values act as independent witnesses of the expected behavior.
Adding dedicated unit tests for StackDepthLimits would just duplicate what these commands already cover with the same hardcoded assertions, so I'd rather not add them unless you feel strongly.
There was a problem hiding this comment.
I see your point about avoiding tautological tests and using hardcoded values as an independent check, that makes sense.
That said, I’m wondering if we might be mixing concerns a bit between unit tests and madhouse tests (just calling them “madhouse” here for distinction, but could be any higher-level test). My thinking is:
We could add focused unit tests for StackDepthLimits::for_epoch that explicitly assert the expected values (including the constants). That would lock in the behavior in a single, well-scoped place.
Then, in madhouse tests, we could rely on StackDepthLimits::for_epoch directly, since at that point we’re more interested in validating system behavior end-to-end (e.g. RelayDeepContract) rather than re-checking the exact computation.
This way:
- The computation is still guarded against accidental changes via dedicated unit tests related to the component that encapsulate the behaviour (which we don’t currently have).
- madhouse tests stay simpler and avoid duplicating logic or constants (and try to cross-reference with the original ones by docstring)
- If the computation ever legitimately changes, we only need to update expectations in one place, avoiding duplication across test layers.
- No duplication between tests because they would be layered (if we dont need additional safeguard).
Do you think this split could work?
| pub fn consensus_buff_type_strategy() -> BoxedStrategy<String> { | ||
| let len_range = 1u32..=128; | ||
|
|
||
| prop_oneof![ | ||
| Just("int".to_string()), | ||
| Just("uint".to_string()), | ||
| Just("bool".to_string()), | ||
| Just("principal".to_string()), | ||
| len_range.clone().prop_map(|n| format!("(buff {n})")), | ||
| len_range | ||
| .clone() | ||
| .prop_map(|n| format!("(string-ascii {n})")), | ||
| len_range.clone().prop_map(|n| format!("(string-utf8 {n})")), | ||
| Just("(optional int)".to_string()), | ||
| len_range.prop_map(|n| format!("(list {n} int)")), | ||
| Just("(response int int)".to_string()), | ||
| ] | ||
| .boxed() |
There was a problem hiding this comment.
sanity-check: should tuple also be considered here?
|
|
Coverage Report for CI Build 24514498135Coverage increased (+0.004%) to 85.716%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions3018 previously-covered lines in 78 files lost coverage.
Coverage Stats
💛 - Coveralls |
radu-stacks
force-pushed
the
test/epoch34-clarity5
branch
from
dfd390f to
80dd989
Compare
7 participants
This PR applies stateless and stateful property-based testing techniques for Epoch 3.4 / Clarity 5 changes.
Stateless (proptest-rs)
secp256r1-verify: digest roundtrip, tamper/wrong-key/malformed-key cases, and version-governance checksStateful (madhouse-rs)
Infrastructure
MADHOUSE=1randomized modecargo test -p stackslib --lib chainstate::tests::madhouseMADHOUSE=1 PROPTEST_CASES=50 cargo test -p stackslib --lib chainstate::tests::madhouse