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

I don't think it's worth breaking tooling / grammars over.

That being said I am in favour of the language dictating that a string in a UDA on a unittest has special meaning (i.e. is a name or description)

On Saturday, 11 February 2023 at 20:05:38 UTC, max haughton wrote:

Wouldn't that only really be useful if the compiler had better support for named unittests, e.g. -test-filer=yada, or -test-output=pretty (similar to silly or something like that)?

Or am I missing the point entirely here :D

On Saturday, 11 February 2023 at 21:10:15 UTC, Bradley Chatha wrote:

In my opinion, the compiler doesn't really need to be responsible for all the bells and whistles in a modern testing framework; it just compiles code or it complains when it can't.

The issue is that we as a community haven't rallied around a single best testing framework which expands upon the basic unittest functionality. Atila's "unit-threaded" might be the best contender so far, but it's not unanimous like pytest for python or junit for java.

On 2/11/23 4:10 PM, Bradley Chatha wrote:

All this is possible. Let me talk a little bit about how this all works.

The compiler takes all unittest blocks compiled in a given module, and creates individual functions from all of them.

Then, the compiler creates one master unittest function for each module, and has that function just call all the individual functions. This is the function pointer that is stored in the ModuleInfo.

That's all that is done from the compiler side. None of this is defined explicitly in the spec or language, so we have free reign to do this however we want.

Now, on the library side, all it does is search all moduleinfos and find any that have unittests. Then it runs those unittests using a function in druntime (or you can register a custom runner if you want). All that library function has accessible in the moduleinfo is the function pointer to run all unittests for that module. The unittest runner returns a structure that indicates how many tests were run (modules), and how many passed. We could easily modify that structure to say how many individual unittests were run (we can do whatever we want in the test running function, it has no explicit specification), and have the test runner collect which tests failed based either on file/line number by default, or use a UDA string if it's provided.

We could easily modify the moduleinfo to contain an array of unittest functions, and run that instead. Each function might even be a tuple of unittest name and function pointer. Then we have the capability to specify which unittests are run.

You can already do this at the module level if desired without any changes (e.g. --runUnittestModule=foo.bar can be acted on properly).

All of it is possible. We are very much unrestricted on how unittests actually run, since the only requirement is that the library run them, and report what happened.

The only thing about this is, it's all doable already with the test frameworks in code.dlang.org. It takes a bit more effort, but it's all available there. You aren't using the ModuleInfo system, but rather compile-time introspection to find unittests. But so what?

So really, it's a matter of how much we want to complicate the existing system to achieve something that is already somewhat achievable. That is the question we have to answer.

-Steve

SDC supports the following syntax:

unittest testname {
  // Test things here....
}

On Sunday, 12 February 2023 at 00:15:22 UTC, deadalnix wrote:

unittest testname {
  // Test things here....
}

This.

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

I'd prefer unittest name {}. For documentation, there are doc comments. For error messages, we could have a standard @description attribute not specific to unittests (or treat an unqualified UDA string as such, or have a special doc section).

On Saturday, 11 February 2023 at 21:25:50 UTC, Andrew wrote:

One of the best things with D is the unit test support and how easy it is to add it so I think it should definitely be in the compiler or at least it should appear to be integrated.

Also what is opinionated is if the unit tests should be in the same file or separate. I'm of the opinion that it should be in the same file as then you are encouraged to create unit tests as well changes to the code can also easily be reflected in unit test. This is a matter of opinion and also if you want to use a third party unit test framework, then you are free to do so.

I welcome named unit tests and it took a long time for it to even be considered.

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

The reason I used a string UDA initially (and, probably why silly does the same thing) is to avoid having to import a symbol to use it there. It's the simplest thing that will work and not "corrupt" production code.

Don't get me started on version(unittest).