Names on unittests can be useful for documentation, a better message on failure, or to selectively run a specific test. D has no built-in way to name unittests, but the most popular library test runner (silly) uses the first string UDA as a name:

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

This isn't too pretty though, and typing parentheses and quotes is annoying (using a QWERTY keyboard with US-layout).

I was thinking it could be improved by either allowing @"string" attributes, similar to @identifier, or by allowing a string literal after the unittest keyword:

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

This would provide a more ergonomic, standardized way of naming tests, and it's a very simple parser change (there's currently nothing allowed between unittest {).

In many other languages, unittests are regular functions with names, but Zig-test has this syntax for comparison:

test "Johny" {
}

Question to the community: do you name tests, and do you like the idea?

On 2/10/23 4:08 PM, Dennis wrote:

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

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

If you are going that route, just unittest Johnny would be fine.

But just to warn you, there's no place to store this in the ModuleInfo, it stores one function pointer for the whole file.

I personally am fine with the requirements to use a UDA.

And I also prefer the simple "first string" method, because one thing that is super-annoying is to have to depend on the unittest library for normal builds (I recently removed this for mysql-native).

-Steve

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

My proposal is purely syntactic sugar, it's exactly the same as adding a first string UDA.

On Friday, 10 February 2023 at 22:24:54 UTC, Dennis wrote:

I like this idea, and I think as @("") has already become the de-facto standard across testing frameworks on DUB we can just make it behave like that and everyone will be happy without breaking changes + it's all quite an easy change for everyone.

Maybe it's a good idea to do some critical thinking about this, but let's not overdo it, I think this solution is quite practical. (though I haven't have critically thought about this yet very much)

Q: what does unittest foo {} do? try to read variable foo? I think if we support that a syntax like unittest(foo) {} would be more consistent, but maybe we should just make it be identifiers that are output as-is into a string. (it would look like function definitions and we could add duplication checking into the compiler)

On 2/10/23 5:24 PM, Dennis wrote:

In that case, I'm not in favor of it. I don't think the first form is so much worse that it needs adjusting:

// existing
@("foo") unittest {
   ...
}

// proposed
unittest "foo" {
   ...
}

-Steve

On Saturday, 11 February 2023 at 00:03:50 UTC, WebFreak001 wrote:

This is kinda constraining, to a single form. If changes are to be done to language, then perhaps it would be best to consider also parameterized tests, interpolated test names, or test names that are not strings at all but something convertible to string.