Tomek S.:
>and even doesn't poke your eyes like most mixin code:)<
Thanks, but no thanks. String mixin hacks don't help, they make the situation
worse.
>then you would see the name of the unit test in the stack trace.<
I'd love to see the stack trace with stock dmd :-) I don't know/remember why
standard dmd has never adopted the old "phobos hack" to show the stack trace.
>This is interesting. How the IDE may help knowing the unittest name?<
What's the point in giving a name to a unittest?
If the unittests have a name, and unittest failures show names too, but the IDE
doesn't know all the names of the unittests of a module, then the IDE can't use
those names well:
- If the IDE knows the names of the unittests of a module it also knows how
many unittests are present, so it can give the percentage of failed unittests.
- IDEs show lists of unittests, with red and green symbols beside them. If the
IDE doesn't know the all names of the unittests, it can show only the unittests
with red symbols :-)
- If the IDE doesn't knows the names of the unittests of a module, it can't
compute other statistics commonly useful for higher level management of tests,
like the test coverage of a project, percentage of tests written by a
programmer, and so on.
>When a test has failed I go to the testing code to see what's up. So I'll see
>any non-ddoc comments someone left there.<
Of course that's a possibility. But IDEs usually show a Window that lists the
unittests, the failed and passed ones, etc. You can move the mouse cursor on a
unittest and the IDE can show you its ddoc, no need to jump to the code. As I
have said this is not an essential feature, but nothing inside the JSON files
is essential to program in D, it's a possible help for external tools.
>... or in a package, or one folder above the package level, or ... ;)<
Right. The three main use cases are probably:
- to disable an unittetest (it can be done with @disable applied on an
unitttes);
- activating unittests only of a module (the one currently worked on);
- activating only a group of unittests.
>Versioning and conditional compilation are the right tools for the job.<
This works, but:
- The code to do it can be a bit messy. (If I have to do something many times
always in the same way, then I prefer clean code that clearly shows my
semantics. This is why D has both version() and debug() in the first place).
- If you are _not_ using an IDE it can become not handy to manage it. Let's say
I want to run the unittests only of the module foobar. I have to put before all
unittests code like: version(modulename) unittest(foo) {...}
Then if I change the module name I have to change them all.
> static if (isVersion!"group1_tag_name" || isVersion!"group2_tag_name" ||
> ... )
> mixin Unittest!("foo_name", {...});
That's a bad solution.
>In a nutshell, I agree with you that unittests would use more features but we
>should explore a (standard?) library solution first, before putting more metal
>into the language/compiler.<
In that list I have not asked for very complex features. One of the main points
of my post was to see if those things can be implemented well in the current
language.
Bye and thank you for your answers,
bearophile
