April 01, 2015
On Wednesday, 1 April 2015 at 14:07:14 UTC, Jacob Carlborg wrote:
> On 2015-04-01 00:02, Idan Arye wrote:
>
>> I think you and I work under different assumptions of the goals for this
>> feature. If we only want unittest names to be something that can be
>> printed when the unittest runner runs the unittests, than a UDA with a
>> string is indeed preferable. If we want something that tools can
>> actually use to refer to a specific unittest, we need a proper
>> identifier(yes, even though it can be implemented in library code
>> because D is Turing-complete...)
>
> The tools should, mostly, use the file and line information.

So now we just need a way to keep a line number unmodified when you add lines above it...
April 01, 2015
On 2015-04-01 20:35, Idan Arye wrote:

> If we could tell the compiler to only build a single, specific test the
> development cycle can become orders of magnitude faster.

There should be a lot of option to run tests:

* Base on a file
* Line number
* Name
* Tag

And so on.

-- 
/Jacob Carlborg
April 01, 2015
On Wednesday, 1 April 2015 at 18:35:14 UTC, Idan Arye wrote:
> The problem is not with running the tests, it's with building them. In heavily templated libraries(like, for example Phobos), building without unittests takes seconds and building with unitetests takes minutes - mainly because the tests need to to many template instantiations. If we could tell the compiler to only build a single, specific test the development cycle can become orders of magnitude faster.

This is fixed by having smaller modules. If test for a single module takes more than few blinks of an eye, something is wrong already.
April 02, 2015
On 2015-04-01 21:16, Dicebot wrote:

> This is fixed by having smaller modules. If test for a single module
> takes more than few blinks of an eye, something is wrong already.

For unit tests, yes. But there are other kinds of tests as well. Integration, functional, user acceptance test and so on.

-- 
/Jacob Carlborg
April 02, 2015
On 2015-04-01 20:49, Idan Arye wrote:

> So now we just need a way to keep a line number unmodified when you add
> lines above it...

I'm not sure what kind of tools you have in mind.

* Print a link which points back to a failing test, requires file and line information

* Running a specific test, requires file and line information, name or a tag

What else do you have in mind?

-- 
/Jacob Carlborg
April 02, 2015
On Tuesday, 31 March 2015 at 21:24:20 UTC, Dicebot wrote:
> I see no value in test names limited to valid identifiers. It is only tiny bit more informative than `unittestXXX` we have already. If we add names, please, let them be proper names that are easy to read.

I'd rather have the name obey the same restrictions as normal function names and keep additional information in optional @description("...")
April 02, 2015
On Thursday, 2 April 2015 at 06:21:53 UTC, Jacob Carlborg wrote:
> On 2015-04-01 21:16, Dicebot wrote:
>
>> This is fixed by having smaller modules. If test for a single module
>> takes more than few blinks of an eye, something is wrong already.
>
> For unit tests, yes. But there are other kinds of tests as well. Integration, functional, user acceptance test and so on.

I don't think anyone is going to put those in a same inline style as unittest blocks, so this is not truly relevant. At least I hope so.
April 03, 2015
On 2015-04-02 22:31, Dicebot wrote:

> I don't think anyone is going to put those in a same inline style as
> unittest blocks, so this is not truly relevant. At least I hope so.

You mean inline with the code it tests? No, I hope so too. I put my unit tests in separate files as well, but that's just the way I prefer it.

-- 
/Jacob Carlborg
May 17, 2019
On Monday, 30 March 2015 at 21:52:35 UTC, Andrei Alexandrescu wrote:
> we need named unittests

4 years have passed. what the status of subj?
May 17, 2019
On Friday, 17 May 2019 at 17:42:16 UTC, KnightMare wrote:
> On Monday, 30 March 2015 at 21:52:35 UTC, Andrei Alexandrescu wrote:
>> we need named unittests
>
> 4 years have passed. what the status of subj?

I am not sure wheter adding named unittests to the language give that much benefit.

Projects developers want to integrate unittest results into build pipelines and having nice reports which shows directly the source code of failing tests. The luxury version is e.g. that Jenkins sent in case of unittest failures an email to the relevant developers.

I use the dub package dunit. It is small, easy, without any dependencies and it creates an QUnit compatible XML report which opens all possibilities mentioned above.

Kind regards
Andre