Named unittests

[KnightMare]

next all is IMO.

Rule #1: what is needed at least 70% of people must be done very 
well in one place and only once (I am not sure only in percent 
number).

Dlang says "We have built-in unit tests!"
well, they looks like https://pasteboard.co/If9olU6.png

(1) sometimes I want to see every named test is OK - its some 
meditation thing.
compiler options (its just my suggestion):
- no unittest extension option - use as now.
- -unittest:M - prints OK for each tested module/file.
- -unittest:N - prints OK for each named test (failed tests 
prints always - that is a point of unit tests). u can use 
-unittest:MN too.
maybe use coloring too.
and I dont thought yet what to do with /SUBSYSTEM:Windows (non 
CONSOLE), maybe create console for tests. maybe such thing 
implemented already.
failed tests should be detailed after all tests.

(2) default assert message "unittest failure" for DMD or 
"Assertion failure" for LDC is shitty.
assert has checked expression already. use it as assert message. 
why not? too many string literals in EXE? ok. add this string 
literals only for version(unittest) only and use current assert 
behavior in other case.

(3) stack traces dont need in unit test. well, let say in 90% of 
running tests (I threw the dice for that number).
and we have here shitty stack trace - no useful info at all. lets 
increase number to 99.99999%.

(4) we can sum totally unit tests in module/file, isn't it?
well, lets print valid numbers for tests
as we can see I have a few blocks of tests: "first tests" is ok, 
"second tests" is failed and I have "3rd tests" that wasn't 
testes after failed second. and in any failed case we see "1/1 
unittests FAILED". are the one is string literal? "1/1" here is 
completely lying. well, I have assert( false ) in 2 unit tests.

back to Rule #1...
Dlang says "We have built-in unit tests!"
lets imagine we come to buy yacht and we see "We have toilet in 
each room!" (weird, but just imagine it)
- and where is toilet? - we asked when we looked at the interior.
- do u see bucket in the corner?..
well, the bucket does its job. well, current unittest does its 
jobs.

when u dont use any unit tests u dont care how it looks like.
80% does. it a big number. I think unittest infrastructure 
should/must be written right once. it is necessary, it deserves 
it and it is worth it.

u can to say "use any unittest library from DUB".
well, lets remove buckets from rooms at all. and in each room 
(3rd-side library) will use biotoilet, japan toilet pan or 
another stuff. and now our projects depends from 3-4 unittest 
libraries even indirectly.
again: needed for 70% people things must be done once for all and 
for any case.

OFFTOPIC 1:
lets talk about C++ std::string. they are 30 years old. and still 
shitty. they needed in probably for 99% of all programs. and they 
are shitty. well, if u need just store chars - its ok, u can live 
with it. but if u need some string manipulation (trim, lower,..) 
- its shitty! (maybe something was changed since C++14+?). u(or 
somebody else) can write awesome string class/type with almost 
needed methods for all of us with using ICU BUT when another man 
brings some another 3rd library with some another string class 
(or even std::string) u will be cursed by your coworkers - adding 
interop between 2-3 types of strings... well, u just cannot use 
another type of string in reality, 3rd libraries used default 
std::string. u have only one(?) exception - u writing ur 
application with Qt with QString and use 3rd libraries for Qt too.
just add extension methods to C++ and add ICU to std::string 
class - C++ strings will be great for all of us.

OFFTOPIC 2:
things that needed for 70% people should/must be written very 
well once in one place.
if u dont use UDA u dont care it. if u use UDA most probably u 
will add some UDAs into project.
lets add @name, @description, @tag, @default(Variant) to Phobos.
why?
somebody wrote awesome JSON serialization library that use or 
field names or some UDAs. and we need another BINARY 
serialization library from another company with another UDAs. 
both UDAs are almost same - name, description... and this is pain 
in ass - override, rename, wrap, interop one library types to 
another. ok, we will not use UDAs for such things, lets library 
use field names.. its same like "we will not use string, we will 
use const char* and we solve the problem"

again:
what is needed at least 70% of people must be done very well.
- Dlang' unittest should be brilliant. they needed for 80+% 
developers. shouldn't be used 3rd libraries for compiler with 
native supports of unit tests. 3rd libraries brings dunit, 
unit-threaded or something else. well, this means Dlang haven't 
built-in unit tests, just the bucket in the corner. change it.
- C++ strings should be brilliant. they needed for 95+% 
C++-developers. compare QString and std::string. I want to cry 
with std::string.
- add some useful UDAs holding in a head XML/JSON. u will make 
friends a bunch of libraries with same UDAs. next UDAs - @name, 
@description, @tag, @defaultValue - will be helpful. add some 
another to this list. and add it to Phobos. dont need bring same 
UDAs from 3rd libraries.