Summary on unit testing situation

[Pelle Månsson]

On 03/23/2010 08:29 PM, bearophile wrote:
> Pelle M.:
>
>> I'm not sure I understand, could you explain?<
>
> That was my best explanation, sorry.
>
>
>> I am not experienced with unittest frameworks, and would like to understand what the D system lacks.<
>
> I think two times in the past I have written a list of those lacking things. To give a good answer to your question I have to write a lot, and it's not nice to write a lot when the words get ignored. So first devs have to agree that a problem exists, then later we can design things to improve the situation. Otherwise it's just a waste of my energy, like trying to talk in vacuum.
>
> Unit testing has to continue when tests fail. All code must be testable, compile-time code too. You need a way to assert that things go wrong too, like exceptions, asserts, compile-time asserts, etc when they are designed to. It's good to have a way to give a name to tests. And unit test systems enjoy some reflection to organize themselves, to attach tests to code automatically. During development you want to test only parts of the code, not the whole program. Unit testing OOP code has other needs, because in a test you may need to break data hiding of classes and structs. If you unit test hundred of classes you soon find the necessity of something to help creation of fake testing objects. You need some tools for creating mock test objects (objects that simulate external resources). You need a help to perform performance tests, to print reports of the testing. You need layers of testing, slow tests and quick tests that you can run every few minutes or seconds of programming
. Generally the more the unit test system does automatically the better it is, because you want to write and use unit tests in the most fast way possible. Those things are useful, but putting most of those things inside a compiler is not a good idea.
>
> The best thing you can do is to write some code in C#/Java/Python/etc and to add some unit tests, so you can learn what's useful and what is not. All unit test systems have some documentation, you can start reading that too. In two days you can learn more than I can ever tell you. If you don't try to use unit testing you probably will not be able to understand my words :-)
>
> Bye,
> bearophile

I see, and I think most of these problems are solvable within the 
language. For example, you could choose not to use asserts in unittests, 
and __traits should help in other cases.

Some of the problems may need a separate framework, so you are probably 
right about the need for improvement.