enhance(LargeSmtForest tests): expand LargeSmtForest property test coverage by AlexWaker · Pull Request #886 · 0xMiden/crypto

AlexWaker · 2026-03-10T07:55:50Z

This PR expands the property-based test coverage for LargeSmtForest.

Previously, the forest-level property tests were mostly limited to entries(). This change adds a broader set of reference-model-driven property tests covering core query, mutation, metadata, constructor, and truncation behavior.

The new tests now exercise:

query consistency for get(), entries(), and entry_count()
selected open() consistency checks against a reference Smt
metadata consistency for latest_version(), latest_root(), lineage_roots(), roots(), and root_info()
mutation behavior for add_lineage(), update_tree(), and update_forest()
failure semantics, including duplicate lineages, bad version transitions, and invalid forest batches
constructor behavior when initializing a forest from a pre-populated backend
retention and visibility semantics for with_config() and truncate()

In addition, the property test helpers and generators were refactored to make the coverage easier to extend and maintain.

Closes #879.

huitseeker · 2026-03-18T09:08:21Z

miden-crypto/src/merkle/smt/large_forest/property_tests.rs

+            .operations(unknown_lineage)
+            .add_insert(query_key, invalid_value);
+        let invalid_result = forest.update_forest(version + 2, invalid_updates);
+        prop_assert!(invalid_result.is_err());


Could we also assert metadata is unchanged after this error path? Right now we re-check entries and queries, but a partial apply bug could still move latest_version or create a new root_info at version + 2 and this test would still pass.

I understand. I'll fix it as soon as possible

huitseeker · 2026-03-18T09:09:24Z

miden-crypto/src/merkle/smt/large_forest/property_tests.rs

+        let bad_version = forest.update_tree(lineage, version, extra_entries);
+        prop_assert!(bad_version.is_err());
+        prop_assert_eq!(
+            bad_version.unwrap_err().to_string(),


Would it be safer to assert the error variant instead of exact to_string() text? Matching full message strings can make this test fail on wording-only changes.

AlexWaker · 2026-03-19T11:57:03Z

Resolved the merge conflict by aligning property_tests.rs with the upstream API changes, including the new fallible entries() usage.

Also addressed the two review comments:

replaced string-based error assertions with matching on concrete error variants
added post-error metadata checks to ensure failed updates do not change lineage/tree metadata or create new root_info entries

Finally, ran formatting checks and applied rustfmt fixes (cargo +nightly fmt --all and cargo +nightly fmt --all --check).

AlexWaker · 2026-03-20T04:20:59Z

Would this PR need a changelog entry?

My understanding is that it probably does not, since this change only expands internal test coverage and adapts the tests to upstream API changes, without introducing any user-facing behavior change or public API change. From the current CHANGELOG.md, it also seems like entries are generally reserved for externally visible features, fixes, and breaking changes.

That said, if you would still prefer one to be added, I can update the changelog right away.

huitseeker

This is shaping up nicely! See comments inline.

huitseeker · 2026-03-23T10:20:49Z

miden-crypto/src/merkle/smt/large_forest/property_tests.rs

+            TreeId::new(lineage, version),
+            &tree_v1,
+            &sample_keys,
+            false,


This helper skips open() on the historical tree by passing false here. Can we also property-test historical open() against the reference Smt? That feels like the trickiest query path in LargeSmtForest, and right now it still looks like it only has the hand-written unit test coverage in tests.rs.

Yeah this should 100% test historical openings as well.

huitseeker · 2026-03-23T10:35:01Z

miden-crypto/proptest-regressions/merkle/smt/large_forest/property_tests.txt

@@ -0,0 +1 @@
+cc abf493f7aece0d6db6c370e3c95651effc9f46f7a2f97e2dccddacfce2afd16d


I don't see any behavioral fixes in this PR. We usually only keep regression seeds like this when they allowed us to identify an interesting failure, which required fixing. This seems like it was just a development artifact and so does not need keeping.

iamrecursion

Looks reasonable in general! I've left a few comments in-line.

One thing I would love to see for every single potential modification is that we assert complete correctness with regards to the state change. Some of these—like the one @huitseeker commented on—do not assert the complete soundness of all propertiess should a bug arise.

Perhaps this is out of scope for this PR, but I would also be interested in expanding the FallibleEntriesBackend to be a more general mechanism for testing state coherence in the face of a number of different kinds of failure. @huitseeker, thoughts?

iamrecursion · 2026-03-23T15:15:19Z

miden-crypto/src/merkle/smt/large_forest/property_tests.rs

 };

-// ENTRIES
+// HELPERS


All of these helpers should be moved to large_forest::test_utils like the other strategies are. I would also expect them to have doc comments, as that is the first line of understanding for someone reading the property test after a failure.

iamrecursion · 2026-03-23T15:16:22Z

miden-crypto/src/merkle/smt/large_forest/property_tests.rs

+
+fn apply_batch(tree: &mut Smt, batch: SmtUpdateBatch) -> core::result::Result<(), TestCaseError> {
+    let mutations = tree
+        .compute_mutations(Vec::<(Word, Word)>::from(batch).into_iter())


This should call batch.consume().into_iter() instead. That guarantees the correct deduplication behaviouor.

iamrecursion · 2026-03-23T15:18:51Z

miden-crypto/src/merkle/smt/large_forest/property_tests.rs

+}
+
+fn sorted_forest_entries(
+    forest: &LargeSmtForest<ForestInMemoryBackend>,


Realistically, this and all subsequent cases that take a forest should be parametric in the backend. While we currently only do these with the in-memory backend, there is no reason that has to remain the case forever.

iamrecursion · 2026-03-23T15:19:24Z

miden-crypto/src/merkle/smt/large_forest/property_tests.rs

+        .collect::<crate::merkle::smt::large_forest::Result<Vec<_>>>()
+        .map_err(to_fail)?
+        .into_iter()
+        .sorted()


What is the purpose of sorting them? Does the default derived Ord implementation order them correctly?

iamrecursion · 2026-03-23T15:21:52Z

miden-crypto/src/merkle/smt/large_forest/property_tests.rs

+    Ok(())
+}
+
+// PROPERTY TESTS


In general, please reorder these property tests to match the method order in the large forest itself. It makes for easier code navigation.

iamrecursion · 2026-03-23T15:22:55Z

miden-crypto/src/merkle/smt/large_forest/property_tests.rs

+            TreeId::new(lineage, version),
+            &tree_v1,
+            &sample_keys,
+            false,


Yeah this should 100% test historical openings as well.

tingyanmac and others added 3 commits March 9, 2026 18:08

first commit

c361c47

Merge branch '0xMiden:next' into issue879

efe2f4e

delete unnecessary contents

da7ee9b

AlexWaker changed the title ~~enhance(): xpand LargeSmtForest property test coverage~~ enhance(LargeSmtForest tests): expand LargeSmtForest property test coverage Mar 10, 2026

This was referenced Mar 10, 2026

Improve property tests for LargeSmtForest #879

Open

Add additional batch endpoints to LargeSmtForest #880

Open

fix conflict

fa521be

huitseeker self-requested a review March 18, 2026 09:10

huitseeker reviewed Mar 18, 2026

View reviewed changes

fix conflict and comments

ad29a09

huitseeker added the no changelog This PR does not require an entry in the `CHANGELOG.md` file label Mar 23, 2026

huitseeker requested a review from iamrecursion March 23, 2026 10:35

huitseeker reviewed Mar 23, 2026

View reviewed changes

iamrecursion reviewed Mar 23, 2026

View reviewed changes

		@@ -0,0 +1 @@
		cc abf493f7aece0d6db6c370e3c95651effc9f46f7a2f97e2dccddacfce2afd16d No newline at end of file

Conversation

AlexWaker commented Mar 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlexWaker commented Mar 19, 2026

Uh oh!

AlexWaker commented Mar 20, 2026

Uh oh!

huitseeker left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iamrecursion left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

AlexWaker commented Mar 10, 2026 •

edited

Loading