Re: unittest under betterC
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
```
Re: unittest under betterC
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
Re: unittest under betterC
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?
Re: unittest under betterC
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.
Re: unittest under betterC
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?
Re: unittest under betterC
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.
Re: unittest under betterC
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.
Re: unittest under betterC
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
Re: unittest under betterC
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.
Re: unittest under betterC
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.
Re: unittest under betterC
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
Re: unittest under betterC
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.
Re: unittest under betterC
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
Re: unittest under betterC
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.
unittest under betterC
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?
