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.
