Summary on unit testing situation

[Paul D. Anderson]

bearophile Wrote:

<snip>

> IV) Keep the built-in unit testing of D, keep them almost as simple as they are now, but somehow add hooks and flexibility to allow to external D code to refine *them* as much as needed (this "external" code can be a Phobos module, or it can be a third-part library written by other people, or it can be born as external lib and added to Phobos later, as it happens often in Python, that's why they say it has "batteries included", such batteries often were not born in the std library), so they can be used in professional situations too. This will increase the complexity of the built-in unit tests, but probably not much. It can increase the complexity of the compiler a little, but I think this extra complexity (some reflection, maybe) can be then used for other purposes too.
> 
<snip> 

> If you agree with me that the better solution is the IV, then those hooks/reflection have to be designed first.
> 
> Bye,
> bearophile

I think your analysis is accurate. Having the simple unit testing built in is better than not having it at all. I use it as much as I can, but I haven't written complex applications -- just library modules, where it's perhaps more suitable.

I'm not having much luck at conceptualizing the hooks/reflection that you refer to. (Might just be a having a slow day.) (Or, I might just be slow!) 

It seems like we need some of the xUnit kind of tools -- test suites, more elaborat assertions, test result reporting (not just halting), named tests, and so on.

What is needed to support that?

* More elaborate asserts can be built from the basic assert. A library of assert templates or functions doesn't need additional compiler support.

* Named tests are essential. I'm surprised names (and qualified names -- test.math.divide, etc.) aren't already available. So this would have to be a part of the package.

* Test suites would depend, I think on having names available. Again, qualification may be necessary -- perhaps to include the modulel name.

* Test running needs to be extended. Running the tests before executing main is better than not running the tests. But, as you say, that's really only suitable for toy programs. We'd need some kind of control -- order of execution, action on failure, etc.

I don't know enough about unit testing or compiler writing to know how much work is involved, but it seems that just a few "small additions" would go a long way.

Paul