You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In miden-base, we would like to be able to write unit tests for private (non-exported) MASM procedures.
Ideally we could write these unit tests as Rust tests (mostly for integration in the Rust test setup and because we can setup the environment a bit better in case tests fail and a developer needs to debug), but this requires the MASM procedures to be exported. For now, we might just export them, but longer term it would be nice to have a better way to do this.
In talking with @bobbinth, one idea was to use procedure annotations (#1434) to conditionally assemble procedures to be either proc in normal usage or export if we want to build a MastForest library to test these procedures through.
A similar idea is to write unit tests directly in MASM behind a #[cfg(test)] like flag through which we could assemble a MASM test program. This would keep the procedure definitions itself cleaner (without cfg annotations on each).
Why is this feature needed?
Ensure correctness of MASM procedures.
The text was updated successfully, but these errors were encountered:
I think if one was to try and have some sort of MASM-native notion of tests, the idea of a #[cfg(test)] module/section that can be used to compile them conditionally is probably the best route there. However, I think MASM itself is too low-level for authoring tests - the tests themselves will require as much, or more, careful review than the procedures being tested, which largely defeats the point. Additionally, we lack important tooling such as property tests, assertions with diffs, etc.
So I think the question then is: is there any reason not to simply have an assembler-wide flag (e.g. called test or something), which assembles a program with all procedures exported. Tests can then be written in Rust, using all the nice test facilities available there, against any procedure in the program. This requires no changes to Miden Assembly itself, and achieves the same goal. The primary difference is that we are not attempting to bake testing into MASM itself, which I think is the right choice. The more we think of MASM as equivalent to, e.g. x86_64 asm, the better IMO.
Feature description
In miden-base, we would like to be able to write unit tests for private (non-
export
ed) MASM procedures.Ideally we could write these unit tests as Rust tests (mostly for integration in the Rust test setup and because we can setup the environment a bit better in case tests fail and a developer needs to debug), but this requires the MASM procedures to be exported. For now, we might just export them, but longer term it would be nice to have a better way to do this.
In talking with @bobbinth, one idea was to use procedure annotations (#1434) to conditionally assemble procedures to be either
proc
in normal usage orexport
if we want to build aMastForest
library to test these procedures through.A similar idea is to write unit tests directly in MASM behind a
#[cfg(test)]
like flag through which we could assemble a MASM test program. This would keep the procedure definitions itself cleaner (withoutcfg
annotations on each).Why is this feature needed?
Ensure correctness of MASM procedures.
The text was updated successfully, but these errors were encountered: