🚀 go-pugleaf

In article <connolly.657825420@convex.convex.com> connolly@convex.com (Dan Connolly) writes:
> I just think that an established testing methodology and tools to support
> it is essential to the GNU project. These tests can be the last word in
> specifications for the software. They can improve the maintenance process,
> and they can increase the confidence users have in the software they
> install.
>
> They add a significant amount of work to the development effort, but I
> really think it pays off.
>
> Comments?

I would agree that some sort of automated regression testing and verification
suite is invaluable, particularly for "products" which are distributed
in source form for a wide variety of systems.  These are very good at
giving you some confidence that the product is working as designed.
However, using them is generally a pass/fail type of situation.  Once
you have a failing product, they don't generally help too much in locating
the problem.

I'd like to put in a plug for my DBUG macro package as a solution to
the localization problem.  Given two machines, one of which runs the
product correctly, and one of which doesn't, you simply turn on as
many of the DBUG options as required and diff the two outputs.  In most
cases, you can find where the two executions diverge within a matter
of minutes.  With some attention to avoiding machine dependent output
in the DBUG trace, you can even use the trace itself as part of the
validation suite.  Retrofiting something the size of GNU C with the
macros takes only a few hours of manual editing.  An EMACS wizard
could probably come up with a lisp package to do most of the work
without human interaction.  Ideally, you just add the macros as you
develop and test the code.

-Fred