Improving unit tests

[Derek Parnell]

On Fri, 07 Nov 2008 08:25:04 -0800, Janderson wrote:

> I'd like to learn about move advanced features that D is missing.

The D language does *not* do unit testing. At best, it provides a place in
which the coder can put their unit testing code and an automated initiation
of the coder's unit test code.

 
> I was originally thinking, maybe unit tests shouldn't be part of D to 
> allow for innovation. However then I though, what about if D's unit 
> tests where extensible though some language syntax?
> 
> Questions:
> 1) What features are missing from D's unit tests that you miss?

** A variation of the assert statement that does not halt execution upon
finding an error. Instead, it just reports the error and moves on to the
next test.

** A method of identifying the failing test other than by file-name and
line-number. 

** A method by by the number of failures and successes are recorded and
reported at the end of execution. Possibly event made availble in symbolic
form to the coder for whatever purposes they choose. eg. Keeping a database
of unit ttest results over time.
 
> 2) Should D decouple unittests from the language or should there be 
> language changes to allow for for more extensible unit tests?

Language changes. Uni testing outside of the language is already possible
by using the 'debug' or 'version' facilities, for examle.

> 3) If you chose "more extensible unit tests" what language features 
> would be needed to make this happen.

In addition to those above...
** Being able to run unit tests on a per-module basis without the need of a
main() function.
** Being able to import and declare symbols so that they are only in scope
for their unit test block.
** Nesting of unit test blocks.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell