Jonathan M Davis:

> While there seem to be a lot of tests, they've turned out to be _really_ 
> helpful 
> and by their very nature, they _need_ to be repetitive.

Repetitive doesn't mean it has to take lot of space. Tests are a cross between 
code and documentation, and both are better not too much redundant.


> Now, some of those could be turned into loops, but that would complicate the 
> code, it would be harder to figure out what failed

I am not sure of this.


> Also, the unit testing model in D and how Phobos is set up isn't really 
> intended 
> to have the unit tests separate from the code.

Then maybe the nature of unittesting in D needs an improvement :-)
(From what I have seen in the last few years, in the process of D design often 
up-front design is furiously refused. Post-problem-patch-driven design is much 
more appreciated in this language. So if problems are found in practical 
unittesting in D, then maybe designers may take in consideration the 
possibility of improving the situation).


> On top of that, many of them need private access, which they can't get in 
> another module.

For some people this is a quite controversial point.
An option may be to modify the compiler so it allows to override protection in 
code contained inside unittest{...}.


> I grant you that there are a lot of unit tests, and ways probably could be 
> found 
> to trim them down,

Just to avoid misunderstandings: deleting unit tests is the thing I have never 
suggested.

Bye,
bearophile

Reply via email to