Unit tests in D

[bearophile]

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