On Thursday, 16 February 2023 at 17:26:20 UTC, bachmeier wrote:
>
> My opinion is that naming a unit test is the wrong approach. If the condition for an `enforce` statement fails, it returns an informative message, not a name attached to the `enforce` statement. Along those lines, I would prefer this:
>
> ```
> unittest {
>   onFailure("Comparison of transformations failed");
>   ...
> }
> ```
>
> Naming unit tests would open up other issues. Would you allow recycling of names? There's no reason you couldn't have variable foo and unittest foo, but that would be confusing to someone learning the language. Would you have to use unique unittest names if you import 30 modules written by someone else? This could probably be resolved without great difficulty at the level of language design, but it's all added complexity that you shouldn't deal with when learning a language.

If one wants to identify the purpose of a particular unittest, then naming it makes sense.

Searching for some attribute within the unittest itself (e.g onFailure("...")) is not the correct approach to solving this particular problem.

Imagine your suggested approach as being the approach for a type, such as:

class()
{
  classID := "This class is for the purposes of creating a car object";
}

No. I prefer to name my class.

I'd prefer to name my unittest also.

On Thursday, 16 February 2023 at 23:33:51 UTC, ProtectAndHide wrote:
>
> If one wants to identify the purpose of a particular unittest, then naming it makes sense.
>
> Searching for some attribute within the unittest itself (e.g onFailure("...")) is not the correct approach to solving this particular problem.
>
> Imagine your suggested approach as being the approach for a type, such as:
>
> class()
> {
>   classID := "This class is for the purposes of creating a car object";
> }
>
> No. I prefer to name my class.
>
> I'd prefer to name my unittest also.

And the naming convention for a unittest should be just as straight forward.

ie. the same as for a class/variable.

There is no need to allow spaces (for example). Of you need a sentence to describe your unittest, that is more about documentation, than naming something.

unittest testThisClass
{

}

unittest testThatClass
{

}

On Thursday, 16 February 2023 at 15:36:25 UTC, Steven Schveighoffer 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

The litmus test for how to go about naming unittests should be what you would do if you didn't know how to do it.

int myInt
struct myStruct
class myClass
unittest myUnitTest (most people would automatically default to this, is my guess)

unittest @myUnitTest (on what basis would people automatically think that this is how to do it?

unittest "my unit test" (again, on what basis would people automatically think that this is how to do it?

It seems like a simple proposition with a simple for the programmer to do it.

Now make the language work for the programmer please, and not the other way around.