digitalmars.dip.ideas - statement unittest
- monkyyy (13/13) Mar 21 I have this code:
- Dom DiSc (18/29) Mar 23 I agree, that looks somewhat ugly. But if you have such short
- Nick Treleaven (2/19) Mar 23 Then you can't have documented unittests for each function.
- Dom DiSc (7/11) Mar 29 If you want to generate documentation from this, every test
- monkyyy (3/22) Mar 23 Theres 30 of these and while all of them should be 1 liners, not
- Nicholas Wilson (10/23) Mar 29 there should be no DIP required here, `unittest`s are function
- Richard (Rikki) Andrew Cattermole (2/12) Mar 29 https://issues.dlang.org/show_bug.cgi?id=24467
- Jonathan M Davis (14/43) Mar 29 Even though it's close, they don't use the normal function syntax. They
- monkyyy (4/6) Mar 29 more tests gooder, I was writing one line tests after one line
- monkyyy (3/4) Mar 29 thats only marginly shorter and I have no idea why you think
- Walter Bright (3/4) Apr 05 It's an interesting idea, but it would close the door on ever having arg...
I have this code:
```d
auto reduce(alias F,R)(R r)=>r.acc!F.last.front;
unittest{ assert(counter(10).reduce!((a,int b=0)=>a+b)==45);}
auto all(alias F,R)(R r)=>r.map!F.filter!(a=>!a).empty;
unittest{ assert([1,3,5,7,9].torange.all!(a=>a%2));}
auto any(alias F,R)(R r)=> ! r.filter!F.empty;
unittest{ assert([1,2,3,4,15].torange.any!(a=>a==15));}
auto count(R)(R r)=>r.reduce!((a,int b=0)=>b+1);
unittest{ assert(counter(10).filter!(a=>a%2).count==5);}
```
"unittest{ assert(..);}" should be reduceable to `unittest(...)`
i.e. `unittest(1==1)` would compile
Mar 21
On Thursday, 21 March 2024 at 19:39:41 UTC, monkyyy wrote:
I have this code:
```d
auto reduce(alias F,R)(R r)=>r.acc!F.last.front;
unittest{ assert(counter(10).reduce!((a,int b=0)=>a+b)==45);}
auto all(alias F,R)(R r)=>r.map!F.filter!(a=>!a).empty;
unittest{ assert([1,3,5,7,9].torange.all!(a=>a%2));}
auto any(alias F,R)(R r)=> ! r.filter!F.empty;
unittest{ assert([1,2,3,4,15].torange.any!(a=>a==15));}
auto count(R)(R r)=>r.reduce!((a,int b=0)=>b+1);
unittest{ assert(counter(10).filter!(a=>a%2).count==5);}
```
I agree, that looks somewhat ugly. But if you have such short
functions and short unittest, why not sort them:
```d
auto reduce(alias F,R)(R r)=>r.acc!F.last.front;
auto all(alias F,R)(R r)=>r.map!F.filter!(a=>!a).empty;
auto any(alias F,R)(R r)=> ! r.filter!F.empty;
auto count(R)(R r)=>r.reduce!((a,int b=0)=>b+1);
unittest
{
assert(counter(10).reduce!((a,int b=0)=>a+b)==45);
assert([1,3,5,7,9].torange.all!(a=>a%2));
assert([1,2,3,4,15].torange.any!(a=>a==15));
assert(counter(10).filter!(a=>a%2).count==5);
}
```
That's pretty much as short as your proposal and even more
readable.
Mar 23
On Saturday, 23 March 2024 at 09:43:20 UTC, Dom DiSc wrote:
I agree, that looks somewhat ugly. But if you have such short
functions and short unittest, why not sort them:
```d
auto reduce(alias F,R)(R r)=>r.acc!F.last.front;
auto all(alias F,R)(R r)=>r.map!F.filter!(a=>!a).empty;
auto any(alias F,R)(R r)=> ! r.filter!F.empty;
auto count(R)(R r)=>r.reduce!((a,int b=0)=>b+1);
unittest
{
assert(counter(10).reduce!((a,int b=0)=>a+b)==45);
assert([1,3,5,7,9].torange.all!(a=>a%2));
assert([1,2,3,4,15].torange.any!(a=>a==15));
assert(counter(10).filter!(a=>a%2).count==5);
}
```
That's pretty much as short as your proposal and even more
readable.
Then you can't have documented unittests for each function.
Mar 23
Dom DiSc <dominikus scherkl.de> On Saturday, 23 March 2024 at 16:28:14 UTC, Nick Treleaven wrote:On Saturday, 23 March 2024 at 09:43:20 UTC, Dom DiSc wrote:If you want to generate documentation from this, every test should at least have one line of comment (aka "Documentation"), so can't be a one-liner anyway. And especially in the description of some closely related functions I would prefer one unittest block testing all of them over the scattered tests between each function declaration.That's pretty much as short as your proposal and even more readable.Then you can't have documented unittests for each function.
Mar 29
On Saturday, 23 March 2024 at 09:43:20 UTC, Dom DiSc wrote:On Thursday, 21 March 2024 at 19:39:41 UTC, monkyyy wrote:Theres 30 of these and while all of them should be 1 liners, not all of them are[...]I agree, that looks somewhat ugly. But if you have such short functions and short unittest, why not sort them: ```d auto reduce(alias F,R)(R r)=>r.acc!F.last.front; auto all(alias F,R)(R r)=>r.map!F.filter!(a=>!a).empty; auto any(alias F,R)(R r)=> ! r.filter!F.empty; auto count(R)(R r)=>r.reduce!((a,int b=0)=>b+1); unittest { assert(counter(10).reduce!((a,int b=0)=>a+b)==45); assert([1,3,5,7,9].torange.all!(a=>a%2)); assert([1,2,3,4,15].torange.any!(a=>a==15)); assert(counter(10).filter!(a=>a%2).count==5); } ``` That's pretty much as short as your proposal and even more readable.
Mar 23
On Thursday, 21 March 2024 at 19:39:41 UTC, monkyyy wrote:
I have this code:
```d
auto reduce(alias F,R)(R r)=>r.acc!F.last.front;
unittest{ assert(counter(10).reduce!((a,int b=0)=>a+b)==45);}
auto all(alias F,R)(R r)=>r.map!F.filter!(a=>!a).empty;
unittest{ assert([1,3,5,7,9].torange.all!(a=>a%2));}
auto any(alias F,R)(R r)=> ! r.filter!F.empty;
unittest{ assert([1,2,3,4,15].torange.any!(a=>a==15));}
auto count(R)(R r)=>r.reduce!((a,int b=0)=>b+1);
unittest{ assert(counter(10).filter!(a=>a%2).count==5);}
```
"unittest{ assert(..);}" should be reduceable to `unittest(...)`
i.e. `unittest(1==1)` would compile
there should be no DIP required here, `unittest`s are function
declarations, and so they _should_ work as `unittest =>
assert(1==1);`. They don't currently though (purely a problem
with the parser[1]), that seems like a bug, please file one.
[1]:
https://github.com/dlang/dmd/blob/e00869b27e3d9cabed2b6e73503561997398759c/compiler/src/dmd/parse.d#L521
explicitly checks for { }
a similar problem exists for `parseUnitTest` that calls
`parseStatement` that explicitly checks for `{}`
Mar 29
On 30/03/2024 12:53 AM, Nicholas Wilson wrote:there should be no DIP required here, `unittest`s are function declarations, and so they _should_ work as `unittest => assert(1==1);`. They don't currently though (purely a problem with the parser[1]), that seems like a bug, please file one. [1]: https://github.com/dlang/dmd/blob/e00869b27e3d9cabed2b6e73503561997398759c/compiler/src/dmd/parse.d#L521 explicitly checks for { } a similar problem exists for `parseUnitTest` that calls `parseStatement` that explicitly checks for `{}`https://issues.dlang.org/show_bug.cgi?id=24467
Mar 29
On Friday, March 29, 2024 5:53:52 AM MDT Nicholas Wilson via dip.ideas wrote:On Thursday, 21 March 2024 at 19:39:41 UTC, monkyyy wrote:Even though it's close, they don't use the normal function syntax. They happen to be implemented as functions, but they're not declared like they're functions. If they used the normal function syntax, then they'd have parens, which they don't. So, I don't see how you can argue that it's a bug that they don't allow the lambda syntax. It's also incredibly bad practice in general to be writing unit tests that only have a single test. So, I really don't see any value in allowing poeple to write something like unittest => assert(1 == 1); And if it ever becomes possible, it should be actively discouraged, because it would be terrible practice to write tests that covered that little. So, we're just better off not try to add new syntax here. - Jonathan M DavisI have this code: ```d auto reduce(alias F,R)(R r)=>r.acc!F.last.front; unittest{ assert(counter(10).reduce!((a,int b=0)=>a+b)==45);} auto all(alias F,R)(R r)=>r.map!F.filter!(a=>!a).empty; unittest{ assert([1,3,5,7,9].torange.all!(a=>a%2));} auto any(alias F,R)(R r)=> ! r.filter!F.empty; unittest{ assert([1,2,3,4,15].torange.any!(a=>a==15));} auto count(R)(R r)=>r.reduce!((a,int b=0)=>b+1); unittest{ assert(counter(10).filter!(a=>a%2).count==5);} ``` "unittest{ assert(..);}" should be reduceable to `unittest(...)` i.e. `unittest(1==1)` would compilethere should be no DIP required here, `unittest`s are function declarations, and so they _should_ work as `unittest => assert(1==1);`. They don't currently though (purely a problem with the parser[1]), that seems like a bug, please file one. [1]: https://github.com/dlang/dmd/blob/e00869b27e3d9cabed2b6e73503561997398759c/c ompiler/src/dmd/parse.d#L521 explicitly checks for { } a similar problem exists for `parseUnitTest` that calls `parseStatement` that explicitly checks for `{}`
Mar 29
On Friday, 29 March 2024 at 12:26:00 UTC, Jonathan M Davis wrote:It's also incredibly bad practice in general to be writing unit tests that only have a single test.more tests gooder, I was writing one line tests after one line functions and had to get `);}` right each time please treat users (like me) like easily distractable children
Mar 29
On Friday, 29 March 2024 at 11:53:52 UTC, Nicholas Wilson wrote:`unittest => assert(1==1);`thats only marginly shorter and I have no idea why you think lambda syntax helps here
Mar 29
On 3/21/2024 12:39 PM, monkyyy wrote:i.e. `unittest(1==1)` would compileIt's an interesting idea, but it would close the door on ever having arguments to unittest blocks.
Apr 05
On Friday, 5 April 2024 at 15:38:28 UTC, Walter Bright wrote:On 3/21/2024 12:39 PM, monkyyy wrote:why? ```d unittest identity(T)(T i){ assert(i==i); } identity(1); identity(13.37); ``` ```d unittest(1==1,"math broke"); ``` I dont think unittest syntax is constrained muchi.e. `unittest(1==1)` would compileIt's an interesting idea, but it would close the door on ever having arguments to unittest blocks.
Apr 05
On Friday, 5 April 2024 at 17:34:43 UTC, monkyyy wrote:On Friday, 5 April 2024 at 15:38:28 UTC, Walter Bright wrote:Instead why not just allow assert to be a top-level statement?On 3/21/2024 12:39 PM, monkyyy wrote:why? ```d unittest identity(T)(T i){ assert(i==i); } identity(1); identity(13.37); ``` ```d unittest(1==1,"math broke"); ``` I dont think unittest syntax is constrained muchi.e. `unittest(1==1)` would compileIt's an interesting idea, but it would close the door on ever having arguments to unittest blocks.
Apr 05
On Saturday, 6 April 2024 at 06:33:07 UTC, Meta wrote:On Friday, 5 April 2024 at 17:34:43 UTC, monkyyy wrote:I dont see a meaningful difference, if it was top level it would probably need a dummy context and a way to be run which will probably come from it acting like a unittestOn Friday, 5 April 2024 at 15:38:28 UTC, Walter Bright wrote:Instead why not just allow assert to be a top-level statement?On 3/21/2024 12:39 PM, monkyyy wrote:why? ```d unittest identity(T)(T i){ assert(i==i); } identity(1); identity(13.37); ``` ```d unittest(1==1,"math broke"); ``` I dont think unittest syntax is constrained muchi.e. `unittest(1==1)` would compileIt's an interesting idea, but it would close the door on ever having arguments to unittest blocks.
Apr 06