On Monday, 13 February 2023 at 12:05:05 UTC, Atila Neves wrote:

I think using @("") is some kind of a hack because if you use a documentation generator, you will have to also add a /// comment to have a nice description of the example. But since there is already a way to explain what a unit test is doing, and I am referring to the /// comment, why don't you just use that comment?

This is what I implemented in trial, and it works great. Currently, the code is parsed using libdparse, but I must admit that it would be great if there would be a trait that gives you the documentation comment of a symbol. I know there were discussions about this a few years ago, and it was decided not to have such a compiler feature.

On Friday, 10 February 2023 at 21:48:00 UTC, Steven Schveighoffer wrote:

I'm actually for that it should be unittest "Johnny" instead of without the quotations. The reason is that we want something that describes the test much as possible and that will often include spaces.

For example:

unittest "Johnny download test fail to find server"

instead of

unittest Johnny download test fail to find server

which certainly will confuse the parser.

You can overcome this by having snake case but that it kind of ugly

unittest Johnny_download_test_fail_to_find_server

With quotation marks we will have more freedom how to name the tests.

On Thursday, 16 February 2023 at 08:29:44 UTC, Bogdan wrote:

People didn't generally attach string UDAs to tests before, so it doesn't intrude and "just works".

IMHO that should go on the function, not the test.

For me at least, because it'd be incredibly annoying to select that test to run in the command line. I think that if you need a comment to explain what the test is doing, then you should rewrite the test.

On Friday, 10 February 2023 at 21:08:38 UTC, Dennis wrote:

Personally I'm not sure if I could find an interesting name for tests, but I can certainly express their intent in a string literal like in Zig.

On Friday, 10 February 2023 at 21:08:38 UTC, Dennis wrote:

@("Johny")
unittest {
	// This unittest is named Johny
}

unittest "Johny" {
    // Has @("Johny") as first UDA
}

module sample;

class X { void foo() {} }

Refer below form -> it can be expanded with addition attribute(s) in future with consistent structure
unittest(name="good", document="class X")
{}
unittest(name="good", document="class X.foo")
{}

name = name of unittest
document = generate document for class X
generate document for function class X.foo

for running test
unitttest=name:"good"
unittest=module:"sample"

name = only run unittest with matching name "good"
module = only run unittest(s) for module "sample"

On 2/16/23 5:40 AM, IGotD- wrote:

I actually prefer without the quotes. Why? Because it matches what we currently do:

struct foo
class bar
unittest baz

In addition, if you make it a string, since D has CTFE, this is going to get confusing:

sneaky.d:
enum Johnny = "Freddy";

othermodule.d:

unittest Johnny {
}

"unittest Freddy failed"

user: huh?

So you have to come up with a name that has no spaces. Are you a programmer or not?

I would couch this by saying, I don't really think we need anything here. The @("Johnny") is good enough for me. In fact, I'm fine without labeling unittests at all, and just looking at the file/line of the failed tests.

-Steve