Removing ddoc and unittest [Was: Re: How does D improve...]

[bearophile]

Walter Bright:

>It is amazing what a difference just a little sugar will do. It puts it past the tipping point. I've run across an awful lot of C/C++ code in my career written by professionals. Very few of those had any sort of organized test code. But the opposite seems to be true with D. By supporting it directly in the syntax, code just looks half-baked if it doesn't have unittests and Ddoc documentation. That little push makes all the difference.

It also helps with the management of code. It makes it easy to enforce a rule of "public functions shall have unit tests and ddoc comments." Before ddoc, the Phobos documentation was an embarrassing mess. I wouldn't exactly call it the greatest now, but the improvement has been spectacular, and ddoc is the driver behind that.<

I use ddoc and unittests all the time, so I love them a lot. Every little bit, function, template, class in my dlibs is heavily unittested (probably more than Phobos), I have tried to cover all weird corner cases too, and that has made the code quite reliable, I have found just few bugs in my code so far (so far probably about 1 bug every 20_000 lines of code, but this sounds too much good to me...).

Unfortunately I have seen lot of D code that doesn't use unittests, for example the code I'm talking about in the announce group:
http://team0xf.com:8080/omg/file/aca17fefefc1/core/Algebra.d

I agree a lot with what you say: lowering the laziness barrier to do something, and adding some standard sugar helps a lot in getting things used. In the Python world they have invented something that lowers such barrier even more, that is doctests:
http://www.python.org/doc/2.5.2/lib/module-doctest.html
(It's wonderdful and allows even a lazy person to write lot of tests. But it requires capabilibies from the language that I think are absent from D still).

In a recent post of mine I was discussing about removing ddoc and unittest from the D language (while putting range controls to all integral values) AND adding features that allow library code to replace them keeping them equally handy (this also allows such features to be debugged ad improved by the D community).

At the moment both the ddoc and uniuttest features of DMD have several bugs and limitations. For example I'd like to give names to unittests, and to run just part of them in a handy way, and have a log of how many of them have failed at the end, instead of stopping at the first wrong assert, etc. I'd like to have a way to catch static asserts or something similar, so inside the unit tests I can also put code that is supposed to fail statically, this helps me test both positive and negative cases. Etc.

So now the interesting question is: what D needs to allow moving ddoc and unittest into its standard library keeping a handy syntax?

ddoc: the -D compilation switch of DMD can be removed, as well as the code that it contains to generate the HTML page. All such code can be moved into a library (and later improved/debugged). A little program can be added into the "bin" directory that is designed just to create such HTML pages. But there's a problem here: such tool has to parse D code, etc, so it's a duplication of efforts, with a risk of growing little differences in the way D code is parsed, etc., that's bad. So the DMD compiler can grow a switch that makes it spit out the result of parsing a D module (for example in Json file format), that such ddoc tool can load (with a pipe too, to avoid putting another file on disk) and use avoiding all the parsing and creating the HTML.

unittest: here I am less sure about what it needs to be done (beside removing the -unittest compilation switch from DMD). I think D has to grow few more handy reflection capabilities, that can be used to write short and a simple unittest library for the standard library. A unittests(name) {} syntax may be kept in the language... I am not sure.

Bye and thank you,
bearophile