Replies: 4 comments
-
or looks good to me, but the |
Beta Was this translation helpful? Give feedback.
-
|
You may use https://github.com/zxch3n/moon-expect Example UsageExample Error MessagesI'd love to make it support something like |
Beta Was this translation helpful? Give feedback.
-
|
Note test is a keyword in MoonBit, but Any other thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
The package |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Motivations
assert_*()no longer panics, returning a test-specificResult[Unit, String]now.I remember the
@assertionpackage was added to the stdlib before tests were switched to return Results. This indicates theassert_*()functions are not "assertions" that don't get in the way of non-test user code. Now the users have to handle the Results properly in production code, especially to deal with theStringerrors.With that said, a "proper" assertion would have to be like:
However, this explicitness of
unwrap()defeats the idea of calling the package@assertion.There is no way to turn off assertions.
This is debatable - Java and Python provide options to turn off assertions at runtime, C/C++ could use some macro tricks, and Rust disallows turning off
std::assertcalls but providesstd::debug_assertthat is excluded in release builds. The@assertionpackage in MoonBit looks more like a testing library to me, especially since it coverseq,ne,true,false, and likely more to add.In addition, we could borrow
debug_assertfrom Rust that 1) panics if evaluated false, 2) is excluded from release builds, 3) does not live in the@assertion(or@test) package, and 4) has no siblings likeeq,neand so on.@assertion.assert...is redundant to type.Typing
@test.assert_eq()feels much more natural than repeating the "assert" word twice.Beta Was this translation helpful? Give feedback.
All reactions