[dmd-internals] test failures

Jonathan M Davis jmdavisProg at gmx.com
Fri May 20 00:36:45 PDT 2011


On 2011-05-20 00:16, Don Clugston wrote:
> On 19 May 2011 17:54, Robert <robert at octarineparrot.com> wrote:
> > On 19 May 2011 12:45, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
> >> How is this related to the size of std.datetime?  It's pretty clear the
> >> failure is on line 842.
> >> 
> >> Just isolate that line and its related setup, and you should find the
> >> minimal test case.  Or am I missing something?
> 
> The "related setup" is the problem. It's scattered all through the file.
> 
> > I believe the issue isn't std.datetime directly, but it takes time to
> > narrow down a testcase from a 30kLoC file, even if you know the exact
> > line that's failing!
> 
> Apart from the size, a particular problem with std.datetime is that it
> has unittests _inside_ struct declarations.
> This makes the code practically unreadable, especially since those
> unittests are enormous, and it makes bisection a very painful, manual
> process. 30K lines with only a few blocks of unittests wouldn't be a
> problem.
> 
> Previously, that single module has cost me at least twenty hours of
> time in bisecting bugs. I've spent a couple of hours on reducing down
> this bug already, and I'm still many hours away from a reduced test
> case. I find this extremely frustrating, since intrinsically it's a
> very simple module. Basically, it's unmaintainable code.

Then what would improve it for you? I'm in the midst of reworking the unit 
tests, which will reduced the number of lines of code that they take up, but 
the tests due ensure that the code stays valid when changes are made. They're 
also far more maintainable when they're right next to what they're testing 
than when they're completely separate from what they're testing, though that 
does tend to separate the functions from each other. Searching and hopping to 
matching braces deals with that pretty well overall though - at least for me. 
If you want the unit tests to all be disabled, then just remove the line

    version = testStdDateTime;

(which is currently line# 143), and then you can enable unit tests that you 
care about individually by removing the version declaration in front of them. 
So, it's easy to stop the unit tests from being compiled in and only compile 
in those that you care about (if any).

Other than reducing the number of lines of codes of the unit tests (which I'm 
in the middle of, though it was partially done for this last release), what 
would help you when have to deal with std.datetime for fixing compiler bugs?

- Jonathan M Davis


More information about the dmd-internals mailing list