digitalmars.dip.ideas - statement unittest v2
- monkyyy (36/36) Apr 28 2024 `unittest => 1==1;`
- Timon Gehr (10/23) Apr 28 2024 The previous proposal with `unittest(expression);` was better.
- Walter Bright (11/12) Mar 15 Which could be written as:
- Quirin Schroll (7/19) Apr 14 It’s the same case as `in` and `out` and `invariant` contracts,
- Atila Neves (4/22) Apr 21 I think they're quite different; unit tests are extremely
`unittest => 1==1;` `unittest math_still_works => 1==1;//generates ddoc` I see roughly 3 criticisms to my last suggestion 1. unittest without docs are bad 2. this is a bug; that should already work (???) 3. we may want agrumented unittests in the future so handling the arguments out of order what? whatever i'll simplify the syntax by not using ()'s I assume it will leave open the door for whatever this theory is I dont care about this in the slightest but... whatever `unittest [name] => code;` if optional `name` exists generate a header and `code` in ddoc name will replace'_'s with spaces, put it in a header followed by a code block of the code so given this code ```d /** * a very important function */ auto foo=>[1,2,3,4,5]; unittest foo_returns_an_array=>foo==[1,2,3,4,5]; ``` will generate the docs ```md a very important function ```d foo==[1,2,3,4,5]; ``` ```
Apr 28 2024
On 4/28/24 15:47, monkyyy wrote:`unittest => 1==1;` `unittest math_still_works => 1==1;//generates ddoc` I see roughly 3 criticisms to my last suggestion 1. unittest without docs are bad 2. this is a bug; that should already work (???) 3. we may want agrumented unittests in the future so handling the arguments out of order... ```The previous proposal with `unittest(expression);` was better. shorthand `out` syntax already show how to do it. So I think all of those objections should be dismissed and you got it right the first time. OTOH `unittest => expression;` is weird because everywhere else `...=>r` just means `...{ return r; }`
Apr 28 2024
On 4/28/2024 5:12 PM, Timon Gehr wrote:The previous proposal with `unittest(expression);` was better.Which could be written as: ``` unittest { assert(expression); } ``` which seems a rather minor improvement. But there is a risk there, if in the future we want to do something like: ``` unittest (parameters) { assert(expression); } ``` where `parameters` would be an extension.
Mar 15
On Sunday, 16 March 2025 at 06:40:46 UTC, Walter Bright wrote:On 4/28/2024 5:12 PM, Timon Gehr wrote:It’s the same case as `in` and `out` and `invariant` contracts, the fact that the concise version exists makes programmers more likely to actually write them. For the cases you point out, the parser can look ahead and see if the closing parenthesis is followed up by a semicolon or an opening brace.The previous proposal with `unittest(expression);` was better.Which could be written as: ``` unittest { assert(expression); } ``` which seems a rather minor improvement. But there is a risk there, if in the future we want to do something like: ``` unittest (parameters) { assert(expression); } ``` where `parameters` would be an extension.
Apr 14
Atila Neves <atila.neves gmail.com> On Monday, 14 April 2025 at 18:16:08 UTC, Quirin Schroll wrote:On Sunday, 16 March 2025 at 06:40:46 UTC, Walter Bright wrote:I think they're quite different; unit tests are extremely unlikely to be one liners, whereas contracts are very likely to be exactly that.On 4/28/2024 5:12 PM, Timon Gehr wrote:It’s the same case as `in` and `out` and `invariant` contracts, the fact that the concise version exists makes programmers more likely to actually write them.The previous proposal with `unittest(expression);` was better.Which could be written as: ``` unittest { assert(expression); } ``` which seems a rather minor improvement. But there is a risk there, if in the future we want to do something like: ``` unittest (parameters) { assert(expression); } ``` where `parameters` would be an extension.
Apr 21