On Friday, 3 September 2021 at 01:08:25 UTC, deadalnix wrote:

The behavior is good for custom test runners or incremental compilation of unittests. Dub projects can use silly to filter tests, and maybe the default dub test runner should be able to do the same. That wouldn't require a change to the -unittest flag though.

I'm sorry to hear you're frustrated with the current situation, but I can't just open a dmd pull request breaking the CLI and dismissing everyone else's use cases and get that merged. If you want to rant a bit to vent your frustration, that's fine by me, but if you want this thread to result in an improvement, you'll need to come up with a specific, feasible proposal.

No, see Steven's post.

On 9/2/21 9:08 PM, deadalnix wrote:

Or I haven't thought about or cared about a problem with unittests ever. I just use dub test or dub -b unittest, and it works as I expect -- all unittests in my project are run, no unittests in dependencies are run. No trash to drown in.

I'm not too concerned with your use cases, as the current system runs just fine for me, and if you don't like it, you can use a fancier test runner that provides more control. I don't see a problem with the existence of external unittest systems. The basic system is designed to allow you complete control if you don't like the default, and the default is fine for most people.

I'm kinda done with this thread anyway, about to kill it...

-Steve

On Friday, 3 September 2021 at 01:08:25 UTC, deadalnix wrote:

First of all, I fully agree.

Second, I was digging out my DMD bug 18843 ("-deps -unittest causes cataclysmic memory usage"), just to throw some more fuel on this trash fire of a debate, and good news: dmd -deps -unittest helloworld.d no longer causes cataclysmic memory usage:

$ cat helloworld.d
import std.stdio; void main() { writeln("Hello World"); }
$ dmd --version
DMD64 D Compiler v2.097.2
Copyright (C) 1999-2021 by The D Language Foundation, All Rights Reserved written by Walter Bright
$ dmd -deps -unittest helloworld.d
dmd2/linux/bin64/../../src/phobos/std/stdio.d(578): Error: undefined identifier `testFilename`
*snip 20 more semi-identical errors*

I don't think I need to add anything here...

On Friday, 3 September 2021 at 12:49:05 UTC, FeepingCreature wrote:

Well, we could add that even though it cause cataclysmic memory usage, the dependency tracking is not done properly, at least for rdmd: https://issues.dlang.org/show_bug.cgi?id=22268

On Monday, 6 September 2021 at 16:35:03 UTC, Walter Bright wrote:

It came in with https://github.com/dlang/druntime/pull/1685 , which also added a lot more control over how the tests could be run.

Old behavior: adding -unittest causes unittest functions to be compiled in and to run before main, and that's it: the program only exited before main on error because that's how assert() failures are handled, and the program continued to run if there were no errors. This perfectly fits the use case of "I want a build of my program with a bunch of extra testing, ala a debug or a non-release build" but required some workarounds to fit the use case of "I want to run all of my unittests, only"

Much of this thread can be listed under complaints about a third use case, "I want to run a single module's tests, only"

On Monday, 6 September 2021 at 16:52:38 UTC, jfondren wrote:

https://github.com/dlang/druntime/pull/1685#issuecomment-256795118

Damn, I don't know who that guy is, but it seems like he foresaw the current mess that we are in.

On Monday, 6 September 2021 at 16:55:30 UTC, deadalnix wrote:

-main wasn't and still isn't a problem for the use case the PR was authored for, of "I want to run all my unit tests, only", and the approach of the PR approach was completely successful at making druntime much more friendly to that use case. It had zero impact on your use case, but you didn't sell it very well by only mentioning what for other uses was a very trivial inconvenience.