[Issue 11783] Make std.datetime unittesting faster

[d-bugmail at puremagic.com]

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



--- Comment #4 from Andrei Alexandrescu <andrei at erdani.com> 2013-12-22 00:10:29 PST ---
(In reply to comment #3)
> I'm divided on this sort of thing, because I tend to think that other modules
> actually test too little rather than std.datetime testing too much as far as
> properly testing goes (I really do think that a lot of our testing is too
> sparse - particularly when it comes to range based functions).

I agree Phobos could use more and better unittests. That's not an argument in
support for the state of affairs with std.datetime's unittests.

On a top-of-the-line machine, testing std.datetime takes 38 seconds to run (in
release mode). On the same machine testing std.algorithm takes 0.15 seconds and
testing std.range takes 0.1 seconds. I agree both std.algorithm and std.range
could use more unittesting, but probably not quite 300x more.

> However,
> std.datetime's tests do need to be refactored, and the fact they take as long
> as they do does stand out and is problematic.

Great, thanks.

> One of the factors involved is the fact that D's exceptions are really slow -
> issue# 9584 - which affects any test verifying that a function throws when it's
> supposed to, and I expect that some refactoring of the order of some of what
> the tests are doing would make them faster, but obviously the number of tests
> involved makes it take longer regardless of what they're doing.

I frankly don't think that's the high level problem in this case.

> One possibility is to section of some of the tests so that they only run when a
> particular version is set so that they don't run normally but can be turned on
> when more thorough testing is warranted. Or I could move some of them into a
> separate test suite (though that would mean that only I would have them, which
> wouldn't be good). Regardless, there are ways to decrease how many tests are
> run during the normal Phobos build without losing the tests. And any speed-ups
> in the tests themselves would obviously also help.

I don't think this is a good solution. I am confident that 4000 lines of code
can be tested thoroughly in a reasonable time budget. 

> Refactoring std.datetime's unit tests have been on my todo list for after I
> finish splitting std.datetime (which is mostly done), but I've been completely
> bogged down at work for the past few months, so I haven't been making any real
> progress on anything D related lately (or anything else outside of work for
> that matter). However, I expect to be able to get back to this sort of thing in
> January or February.

Good luck with work, of course it takes priority. I will try to make time for
this myself, the situation has gotten quite bad.

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