[rfc] plans for linespec.c

[David Carlton]

On Wed, 8 Jan 2003 22:24:08 -0600, Michael Elizabeth Chastain <mec@shout.net> said:
> Hi David,

>> ... I'm not sure that your level of concern is warranted.  My machine
>> is old, so it would turn a 10-minute testing process into a 20-minute
>> testing process; I'm happy to do that if you think it's important,
>> but I'm not sure that it is in this particular instance.

> It's kinda subjective.  I tend to be conservative about these
> things, and I tend not to think of testing as getting in the way of
> my work flow (I like to proofread while the tests are running).  So
> it's not "you should I do this or I predict calamity" issue.  If you
> choose not to, I won't kick.  If lots of new stabs+ regressions show
> up then I will want it more.

Fair enough.  It's something I should get around to doing eventually
for other reasons; maybe your nudging will move it up some.

>> (I am, however, worried about problems that the test suite might not
>> catch at all: it would be nice if somebody were to make sure that the
>> testsuite systematically tested everything that decode_line_1 does.
>> But that's another issue entirely.)

> Grin.  You are the expert on coverage cases for decode_line_1 now!

There's actually an interesting question here as to whether or not I
even can design coverage tests for the original version of
decode_line_1: my only understanding of the function comes from
decomposing it, so any tests that I'd design would be compromised by
the assumption that I've preserved the behavior by that
decomposition.  Though, obviously, I'd be in a good position for
designing coverage tests for the newer version.

> Unfortunately it's very difficult psychologically to work on a piece
> of code and then write test cases designed to break it.

I'm trying to get better at writing test cases.  My next task for my
non-GDB programming project is to get a unit test system running, both
for new code and for existing code, so hopefully test writing will get
easier for me.

Speaking of which, I had the thought that maybe we could do unit tests
of some of the innards of GDB by writing separate test programs that
we link with -lgdb.  Something to think about.

David Carlton
carlton@math.stanford.edu