datetime review part 2 [Update 4]

Steven Schveighoffer schveiguy at yahoo.com
Wed Nov 10 07:12:23 PST 2010


On Tue, 09 Nov 2010 18:48:30 -0500, bearophile <bearophileHUGS at lycos.com>  
wrote:

> Yao G.:
>
>> Ugh. The datetime.d file is 1.5 MB? 0_o

So it will be very well tested :)  Look, the huge benefit of unit tests  
are that they are inline with the code.  Either you want that or you want  
small files, I don't understand the expectation that the file should be  
small and compact as long as the implementation is...

I 100% agree with Jonathan, just ignore the unit tests, and look at the  
API.  (BTW, this is where a nice doc generator like the one Tango uses  
would come in handy -- it shows the implementation if you click on the  
function name).

> My suggestions:
> - Keep only 5-10% of the tests inside the datetime.d module, and move  
> the other 90-95% in a separated datetime test module.
> - Use deterministic (repeatable) random data in a loop to perform some  
> compact fuzzy testing
> - Use alias or string mixing to greatly reduce the amount of text  
> contained in the tests. Tuples help a lot. All those lines may be  
> replaced with a single loop that contains something like:
> assertEqual(SysTime(DateTime(z0, x1, x2, x3, x4, x5),  
> FracSec.from!"msecs"(x6)).dayOfGregorianCal, x7)
> Where the xn data comes from an array of typecons.Tuples like:
> Data5(2010, 11, 1, 23, 59, 59, 999, 734_077)

Well, I'm not certain that this is the reason, but calendars are riddled  
with corner cases.  I would expect a well-tested date/time library to test  
all those corner cases.

I know when writing the Date/Time code for Tango, there were quite a few  
odd cases to test.

As long as the corner cases are tested, I think the rest of the fluff  
could possibly be reduced.  However, on the other hand, unit tests cost  
nothing except to make the low-file-size purists cringe :)  I say leave  
them all in, there are no requirements on the size and style of unit  
tests, just that they fully test the library.

-Steve


More information about the Digitalmars-d mailing list