www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - unittest under betterC

reply DLearner <bmqazwsx123 gmail.com> writes:
Neither:
```
extern(C) int foo() {

    return 4;
}

unittest {

    assert(foo() != 4, "!= Assert triggered.");
    assert(foo() == 4, "== Assert triggered.");
}
```


Nor:
```
int foo() {

    return 4;
}

unittest {

    assert(foo() != 4, "!= Assert triggered.");
    assert(foo() == 4, "== Assert triggered.");
}
```

Triggers anything with:
```
dmd -betterC -main -unittest -i -run foo
```
Any ideas?
Jun 04 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
Unittests require some mechanism to execute them.

Druntime provides this capability by default.

You can do it manually by using ``__traits(getUnitTests)`` to get access 
to the symbols.

Personally I just use full D for unittests.
Jun 04 2023
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Sunday, 4 June 2023 at 20:43:17 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 Unittests require some mechanism to execute them.

 Druntime provides this capability by default.

 You can do it manually by using ``__traits(getUnitTests)`` to 
 get access to the symbols.

 Personally I just use full D for unittests.


Then this needs to be fixed asap, unittest needs to work for the 
flags user will use

D should not advertise broken features to the world with "deal 
with it" as workaround, this is not a new language, let's up out 
standard of quality
Jun 04 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 05/06/2023 9:20 AM, ryuukk_ wrote:

 Then this needs to be fixed asap, unittest needs to work for the flags 
 user will use


There is nothing to fix.

You literally do not have any of the druntime code needed to handle 
ModuleInfo and hence call via it.

Nor do you have the entry point handled for you to call the functions...

This isn't a language only feature, its also a runtime feature. Just 
like module constructors are.
Jun 04 2023
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Sunday, 4 June 2023 at 22:14:59 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 05/06/2023 9:20 AM, ryuukk_ wrote:

 Then this needs to be fixed asap, unittest needs to work for 
 the flags user will use


 There is nothing to fix.

 You literally do not have any of the druntime code needed to 
 handle ModuleInfo and hence call via it.

 Nor do you have the entry point handled for you to call the 
 functions...

 This isn't a language only feature, its also a runtime feature. 
 Just like module constructors are.


I don't know how all this works, but the runtime shouldn't know 
about tests, imagine if you ship a game, and the player can run 
all the unittests, that doesn't make sense

The compiler should run the unittest, the compiler should run the 
unittest, no matter what flag the programmer is using, in that 
case: -betterC

If not, then it is a design flaw that needs to be fixed

You guys should read what you suggest to people sometimes, i 
repeat, D is not a new language, and D is not the only language, 
provide greatness to people, not dumb and broken stuff

Up your standard of quality
Jun 04 2023
next sibling parent DLearner <bmqazwsx123 gmail.com> writes:
On Monday, 5 June 2023 at 03:42:20 UTC, ryuukk_ wrote:
[...]

 I don't know how all this works, ...


For what it is worth, running _both_ the above code fragments 
with:
```
dmd -main -unittest -i -run foo
```

(ie removing the -betterC flag)

produces:
```
foo.d(8): [unittest] != Assert triggered.
1/1 modules FAILED unittests
```

which is what was expected.
Jun 05 2023
prev sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 05/06/2023 3:42 PM, ryuukk_ wrote:

 I don't know how all this works, but the runtime shouldn't know about 
 tests, imagine if you ship a game, and the player can run all the 
 unittests, that doesn't make sense


Currently that is not possible. When you turn on unittests to be 
compiled in, that runtime will automatically run them and then end the 
program.


 The compiler should run the unittest, the compiler should run the 
 unittest, no matter what flag the programmer is using, in that case: 
 -betterC


Run what?

Until its in a binary on the target platform (which may not be the 
host), there is nothing to run.

Running using CTFE will not allow for testing for things that are 
platform dependent. Which we do plenty of.


 You guys should read what you suggest to people sometimes, i repeat, D 
 is not a new language, and D is not the only language, provide greatness 
 to people, not dumb and broken stuff


It's not broken. It's working exactly how it needs to work.

You can't expect a runtime dependent feature that has no way of working 
without a runtime, to work without a runtime.
Jun 05 2023
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Monday, 5 June 2023 at 11:41:08 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 05/06/2023 3:42 PM, ryuukk_ wrote:

 I don't know how all this works, but the runtime shouldn't 
 know about tests, imagine if you ship a game, and the player 
 can run all the unittests, that doesn't make sense


 Currently that is not possible. When you turn on unittests to 
 be compiled in, that runtime will automatically run them and 
 then end the program.


 The compiler should run the unittest, the compiler should run 
 the unittest, no matter what flag the programmer is using, in 
 that case: -betterC


 Run what?

 Until its in a binary on the target platform (which may not be 
 the host), there is nothing to run.

 Running using CTFE will not allow for testing for things that 
 are platform dependent. Which we do plenty of.


 You guys should read what you suggest to people sometimes, i 
 repeat, D is not a new language, and D is not the only 
 language, provide greatness to people, not dumb and broken 
 stuff


 It's not broken. It's working exactly how it needs to work.

 You can't expect a runtime dependent feature that has no way of 
 working without a runtime, to work without a runtime.


In my book this is broken and needs to be fixed, as a user i 
don't care about under the hood things, it's a you problem, user 
should be able to unit test
Jun 05 2023
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 06/06/2023 2:16 AM, ryuukk_ wrote:

 In my book this is broken and needs to be fixed, as a user i don't care 
 about under the hood things, it's a you problem, user should be able to 
 unit test


If you as the user disable key components required for the language to 
fully work, its a you problem, not a compiler developer problem.

This is true in C just as much as it is in D.

If you want to go at it alone, you have to accept the consequences of 
your actions.
Jun 05 2023
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 5 June 2023 at 14:16:39 UTC, ryuukk_ wrote:


 In my book this is broken and needs to be fixed, as a user i 
 don't care about under the hood things, it's a you problem, 
 user should be able to unit test


The docs say it should work:

https://dlang.org/spec/betterc.html#unittests

So either the docs are wrong or the implementation is bugged. If 
there's no issue yet, could you please file one?
Jun 05 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 06/06/2023 2:25 AM, Mike Parker wrote:

 On Monday, 5 June 2023 at 14:16:39 UTC, ryuukk_ wrote:
 

 In my book this is broken and needs to be fixed, as a user i don't 
 care about under the hood things, it's a you problem, user should be 
 able to unit test


 
 The docs say it should work:
 
 https://dlang.org/spec/betterc.html#unittests
 
 So either the docs are wrong or the implementation is bugged. If there's 
 no issue yet, could you please file one?


Yes that is what I recommended earlier in the thread. But automatic 
running requires druntime.
Jun 05 2023
parent Mike Parker <aldacron gmail.com> writes:
On Monday, 5 June 2023 at 14:29:35 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 06/06/2023 2:25 AM, Mike Parker wrote:

 On Monday, 5 June 2023 at 14:16:39 UTC, ryuukk_ wrote:
 

 In my book this is broken and needs to be fixed, as a user i 
 don't care about under the hood things, it's a you problem, 
 user should be able to unit test


 
 The docs say it should work:
 
 https://dlang.org/spec/betterc.html#unittests
 
 So either the docs are wrong or the implementation is bugged. 
 If there's no issue yet, could you please file one?


 Yes that is what I recommended earlier in the thread. But 
 automatic running requires druntime.


Ah, I see now. It's working as expected then.
Jun 05 2023
prev sibling parent reply DLearner <bmqazwsx123 gmail.com> writes:
On Monday, 5 June 2023 at 14:25:33 UTC, Mike Parker wrote:

 [...]

 The docs say it should work:

 https://dlang.org/spec/betterc.html#unittests

 [...]


Thank you for the link, can confirm that:
```
int foo() {

    return 4;
}

unittest {

    assert(foo() != 4, "!= Assert triggered.");
    assert(foo() == 4, "== Assert triggered.");
}

extern(C) void main()
{
     static foreach(u; __traits(getUnitTests, __traits(parent, 
main)))
         u();
}
```
run via:
```
dmd -betterC -unittest -i -run foo2
```
works as expected.


However, as a suggestion to create a consistent experience with 
'Full D',
should not the combination of '-main' and '-betterC' cause the 
generation
and attachment of the boilerplate code
```
extern(C) void main()
{
     static foreach(u; __traits(getUnitTests, __traits(parent, 
main)))
         u();
}
```
to a source file containing just the original function and it's 
unittests?
Jun 05 2023
parent reply Ernesto Castellotti <erny.castell gmail.com> writes:
On Monday, 5 June 2023 at 18:14:31 UTC, DLearner wrote:

 On Monday, 5 June 2023 at 14:25:33 UTC, Mike Parker wrote:

 [...]


 Thank you for the link, can confirm that:
 ```
 int foo() {

 [...]


It's not so easy to deal automatically in case of multiple modules
Jun 05 2023
parent DLearner <bmqazwsx123 gmail.com> writes:
On Monday, 5 June 2023 at 18:22:45 UTC, Ernesto Castellotti wrote:
[...]

 It's not so easy to deal automatically in case of multiple 
 modules


_multiple modules_

The following code, in a batch (.bat) file, works for me:
```
 echo off
:loop
if [%1]==[] goto loopexit
type .\%1.d > .\__temp_%1.d
echo extern(C) void main() { static foreach(u; 
__traits(getUnitTests, __traits(parent, main)))   u();} >> 
.\__temp_%1.d
dmd -betterC -unittest -i -run .\__temp_%1.d
del .\__temp_%1.d
shift
goto loop
:loopexit
```
Jun 06 2023