[Issue 11783] Make std.datetime unittesting faster

[d-bugmail at puremagic.com]

https://d.puremagic.com/issues/show_bug.cgi?id=11783



--- Comment #9 from Jonathan M Davis <jmdavisProg at gmx.com> 2013-12-22 04:53:05 PST ---
> Jonathan, I seem to have difficulty getting my point across and the longer the
responses become the larger the disconnect.

Yes. It does look that way. Maybe this would go better if I were better at
being concise.

> 1. Dates and times are special in ways that make them impossible to test in
> less than an ungodly long amount of time.

Not at all. The issue is that the tests need to be very thorough and that that
can be expensive timewise. That does not mean at all that they have to take as
long as they currently do. My objection is only to reducing how thorough the
tests are. I'm sure that it's possible to refactor them so that they take less
time without reducing how much they test.

2. Again, it's the exceptions that make things so slow; there's no way to
> improve timing without cutting down on essential tests.

The exceptions _are_ slow and contribute to the problem, but I'm sure that
they're not the whole the problem. I brought them up as a likely place where
small changes could provide large gains. I did not mean to try and claim that
they were the whole problem, but maybe my frustration with them being slow made
me come across that way. Regardless of how much the exceptions cost, the other
tests do definitely need to be optimized.

I guess that I never should have brought up the exceptions. Along with bringing
up _assertPred, I was trying to give suggestions as to where some likely
culprits for the slow tests might be beyond simply the number of tests. I was
not trying to give excuses for the quality of my code or its tests.

> 3. It seems I am the only person who has a problem with a 38 seconds test on
> modest functionality. Furthermore, the engineering solution proposed is,
> again, to remove some tests with the note that that actually is a bad thing.

I completely agree that 38 seconds is too long. That needs to be significantly
reduced. However, what I don't want to do is reduce it by simply reducing the
number of tests. Experience has shown me (and other developers who I've talked
to agree with me - e.g. Steven Schveighoffer who did the Tango time stuff years
ago) that date/time-related tests need to be thorough because of all of the
corner cases, many of which are hard to know because they depend on quirks of
the calculations being done. Maybe the number of tests will have to be reduced
in order to get the time down, but if I can, I'd very much prefer to get the
time down by optimizing the tests, which I believe can be done.

> They fail to discuss or even so much acknowledge the simple matter that
> std.datetime has its own grave issues. I very much disagree with this view and
> the general attitude that the problem is in various other places than simply
> inside std.datetime and the way its unittests are engineered. If one were to
> take at face value these increasingly long replies, the only logical
> conclusion one could draw is that std.datetime is perfectly engineered and the > only way to make its unittests any faster is to improve the compiler
> implementation.

I do not claim for a second that std.datetime is perfectly engineered, and I
definitely don't claim that the tests are perfectly engineered. They were
written to be thorough, not fast. And clearly they need to be refactored so
that they're much faster than they are. I just don't want to get in a situation
where what's being tested is reduced in order to get the test times down, as I
believe that that will significantly increase the risk of bugs whenever the
code being tested is refactored. If anything, I'm very concerned about having
thorough testing because I feel that my code quality would be at much greater
risk without it.

Maybe I'm too touchy on this subject and come across badly, for which I'm
sorry. But I believe very strongly that code in general (not just std.datetime)
needs to have very thorough testing, and so I tend to object to attempts to
reduce the number of tests of any code. A natural side effect of such testing
is that it can get too expensive, which requires better optimizing it and being
more careful with how you go about testing in order to avoid having the tests'
running time increase too much. And clearly, I have not managed to do that with
std.datetime, and that needs to be fixed.

I've been meaning to refactor std.datetime's unit tests but have not made it a
high enough priority. Clearly, that needs to be among my highest priorities
with regards to the work I do on D.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------