digitalmars.D - Proposal: Enhancing unittest with Inline Module-Level Statements
- Sharif yt (38/38) Nov 19 Hello D enthusiasts,
- Jonathan M Davis (12/28) Nov 20 Personally, I think that it will just encourage writing poor unit tests.
- monkyyy (3/18) Nov 20 making things annoying doesn't make me do them right
- ryuukk_ (2/24) Nov 20 unittest in the middle of a function is bad, to stay polite
- Salih Dincer (29/38) Nov 20 I agree with Jonathan. In addition, instead of the ordinary
Hello D enthusiasts,
One of D's standout features is its built-in unittest, which
makes writing and maintaining test cases seamless and integrated.
However, while working with the current unittest block structure,
I’ve been experimenting with a more concise module-level
statement for simpler assertions.
Inspired by an idea I came across (and expanded upon), this
approach allows inline assertions using unittest() with
parentheses instead of braces {}. Here’s an example:
d
Copy code
unittest(1 == 1);
unittest(1 == 1, "Math broke");
Why Consider This?
Simplicity: For single assertions, it reduces boilerplate while
still maintaining clarity.
Optional Messages: Helps document why the assertion exists
without cluttering the code.
Integration
https://menuland.ph/contis-cake-delivery-menu-in-philippines/
with Existing Framework: This would complement, not replace, the
current unittest block style.
Potential Benefits
Makes quick checks in small modules or scripts easier.
Encourages more frequent, lightweight assertions, especially for
debugging.
Possible Challenges
Parsing implications—ensuring it works well alongside the
existing block-based structure.
Balancing clarity in larger modules where inline and block styles
might mix.
What do you think about extending D's unittest capabilities in
this way? Could it make testing in D even more accessible and
enjoyable?
Here’s the full implementation concept if you're curious: Gist
Link.
Looking forward to your thoughts!
Best regards,
Nov 19
On Tuesday, November 19, 2024 11:11:58 PM MST Sharif yt via Digitalmars-d wrote:Hello D enthusiasts, One of D's standout features is its built-in unittest, which makes writing and maintaining test cases seamless and integrated. However, while working with the current unittest block structure, I’ve been experimenting with a more concise module-level statement for simpler assertions. Inspired by an idea I came across (and expanded upon), this approach allows inline assertions using unittest() with parentheses instead of braces {}. Here’s an example: d Copy code unittest(1 == 1); unittest(1 == 1, "Math broke");What do you think about extending D's unittest capabilities in this way? Could it make testing in D even more accessible and enjoyable?Personally, I think that it will just encourage writing poor unit tests. Properly testing a function requires far more than a line or two unless the functions is absolutely trivial. And if you're writing more than a line or two, it just makes more sense to use the unittest blocks that we have. We should be encouraging more thorough testing, and this would do the exact opposite of that. So, IMHO, this would be adding more complication to the language just to try to make it easier to write inadequate tests, and I don't think think that we should be doing that. - Jonathan M Davis
Nov 20
On Wednesday, 20 November 2024 at 09:48:06 UTC, Jonathan M Davis wrote:On Tuesday, November 19, 2024 11:11:58 PM MST Sharif yt via Digitalmars-d wrote:making things annoying doesn't make me do them right[...][...]Personally, I think that it will just encourage writing poor unit tests. Properly testing a function requires far more than a line or two unless the functions is absolutely trivial. And if you're writing more than a line or two, it just makes more sense to use the unittest blocks that we have. We should be encouraging more thorough testing, and this would do the exact opposite of that. So, IMHO, this would be adding more complication to the language just to try to make it easier to write inadequate tests, and I don't think think that we should be doing that. - Jonathan M Davis
Nov 20
ryuukk_ <ryuukk.dev gmail.com> On Wednesday, 20 November 2024 at 17:10:30 UTC, monkyyy wrote:On Wednesday, 20 November 2024 at 09:48:06 UTC, Jonathan M Davis wrote:unittest in the middle of a function is bad, to stay politeOn Tuesday, November 19, 2024 11:11:58 PM MST Sharif yt via Digitalmars-d wrote:making things annoying doesn't make me do them right[...][...]Personally, I think that it will just encourage writing poor unit tests. Properly testing a function requires far more than a line or two unless the functions is absolutely trivial. And if you're writing more than a line or two, it just makes more sense to use the unittest blocks that we have. We should be encouraging more thorough testing, and this would do the exact opposite of that. So, IMHO, this would be adding more complication to the language just to try to make it easier to write inadequate tests, and I don't think think that we should be doing that. - Jonathan M Davis
Nov 20
On Wednesday, 20 November 2024 at 09:48:06 UTC, Jonathan M Davis wrote:On Tuesday, November 19, 2024 11:11:58 PM MST Sharif yt viaI agree with Jonathan. In addition, instead of the ordinary `assert()`, I use the following `assert_eq()`, inspired by Rust. This gives me 2 extra usage featıres. ```d alias equal = assert_eq; template assert_eq(string msg = "error", R) { enum pred = "a != b"; bool assert_eq(in R p, in R q) { static if (imported!"std.range".hasLength!R) { import std.algorithm : equal; if (p.equal!pred(q)) goto _error_; } if (p != q) _error_: static if (msg.length) assert(0, msg); else return 0; return 1; } } ``` SDB 79... Inspired by an idea I came across (and expanded upon), this approach allows inline assertions using unittest() with parentheses instead of braces {}...... So, IMHO, this would be adding more complication to the language just to try to make it easier to write inadequate tests, and I don't think think that we should be doing that.
Nov 20