Unittests

dhasenan Joined: 02/03/05 Posts: 18

Posted: 10/10/07 01:33:00 'grep -R unittest . | wc -l' on the Tango source gives 220 unittests for a project of 50,000 lines or so. (Phobos has about 330 for 30,000 lines of code, which isn't much better.) What is the policy for unittests in Tango? If I submit patches to provide unittests for large portions of Tango, will they be accepted? Where should I start? It's my fault, isn't it.

Author	Message
dhasenan Joined: 02/03/05 Posts: 18	Posted: 10/10/07 01:43:54 Just to make this clear: if I have my way, the unittests will be exhaustive and probably take up another fifty thousand lines of code. It's my fault, isn't it.
kris Joined: 03/27/04 Posts: 581	Posted: 10/10/07 03:44:55 lol! What you propose sounds awesome, but I'm trying to think of an easy way to merge as things change .... I suspect if you were to group the unittests into one place, such as the end of each module, then merging would be a whole lot easier? Then, I guess a patch-file would be the best way to expose the changes? You can attach SVN patch files to tickets, and we could try one or two modules out to see if that approach works? Any other suggestions?
dhasenan Joined: 02/03/05 Posts: 18	Posted: 10/10/07 12:34:43 I was already thinking of placing all the unittests together due to the code guidelines ("Thou shalt wrap thy unittests in version(UnitTest?)"). It would annoy me to write "version (UnitTest?) unittest {}" every time. There's currently a ticket asking for unittests for the collections, including multithreaded tests. I guess I'll start there. Given the version(UnitTest?) directive, it should be simple enough to import Tango's threading module only when running the tests. There's a script in trunk/lib to run the unittests; I shall assume (hope, pray) that everyone runs that before committing. Maybe I could augment or replace it with a DSSS target? I imagine most people build before committing, at the least, so it would likely be more convenient. It's my fault, isn't it.
Don Clugston Joined: 10/05/05 Posts: 6	Posted: 10/10/07 13:57:47 grep -R unittest . | wc -l' on the Tango source gives 220 unittests for a project of 50,000 lines or so. (Phobos has about 330 for 30,000 lines of code, which isn't much better.) There are almost 100 unittests in tango.math... I've found a lot of really obscure bugs that way. Thoroughly recommended. It is a lot of work though. (It's actually been the biggest effort in converting the Cephes code to D, but it's where most of the value adding comes from).
dhasenan Joined: 02/03/05 Posts: 18	Posted: 10/10/07 22:36:38 -- Modified: 10/10/07 22:44:08 by dhasenan From an end user's standpoint, there are a few concerns with a collection, aside from performance: - Is it ordered? According to opCmp, or insertion order? - Does it allow duplicates? - Is it a dictionary? Most, if not all, tests will be almost identical between different collections. I've added an attachment on http://dsource.org/projects/tango/ticket/228 that offers a template to do the basic stuff. I'll add others for ordering and duplicates. Then I'll do stuff for dictionaries. The attachment I posted is redundant in itself; I'll change it to use a template function to do most of the work. Then there should only be eight lines in the GenericCollectionTest? template. Edit: that's not so easy, either, what with creating objects. Hmmm. This half-compile-time-half-run-time stuff is slightly tricky.