Removing ddoc and unittest

[Christopher Wright]

bearophile wrote:
> Christopher Wright:
> 
>> For what it's worth, dunit supports this:
>> tests["no expected exception"] = {};
>> tests["fails if it doesn't throw"] = expectedException!(AssertError) = {
>> assert(false); };
> 
> I don't understand that syntax.

It's motivated by the lack of reflection in D1.

In dunit, you first make a test fixture:
class FooTests : TestFixture
{
}

Then in the constructor, you define tests:
class FooTests : TestFixture
{
	this ()
	{
		tests["test 1"] =
		{
			assert (1 < 2);
		};
	}
}

A filter just goes in between the test name and the test body:
class FooTests : TestFixture
{
	this ()
	{
		tests["test 1"] = expectedException!(AssertError) =
		{
			assert (!(1 < 2));
		};
	}
}

>>> 4) I'd like to unittest nested functions too.<<
>> That's not going to be easy.<
> 
> It's not too much important.
> 
> 
>> This is interesting. It's not as flexible as dunit or D's unittest blocks -- it'll complain about any user-visible changes to a function. It also looks like it'd be annoying to use, say, mock objects with it. I would have no use for doctests, but I think it's a neat hack.<
> 
> I use it every day and I find it very useful, but note it's not meant to replace normal unittests (in Python for them you use the unittest module of the std lib, or a system you can find online, like "nose"), it's mailing meant to write "documentation tests", that is to write normal documentation that also contains and shows some usage examples: with doctests you can be sure that documentation never goes out of sync with the code, because it's documentation that runs.

For that, it looks like it would work quite well, as long as it's kept 
up to date. And being machine verifiable, it should be easy to find out 
what's outdated.

> Bye,
> bearophile