Linux standards

[John Chambers]

Jerry Feldman writes:
| John,
| I'm surprised at you. You know that we Unix developers never need to test
| our code :-).

Heh.  Actually, isn't that what we've always  claimed  that  IBM  and
Microsoft developers do? Ship it and let the customers tell you about
the bugs.  Of course, I've seen a comparison of this  with  the  Open
Source approach:

IBM/Microsoft:
  It compiled.  Ship it and let the customers report the bugs.

Open Source:
  It compiles; commit it to sourceforge and announce a  new  version.
  Those  thousands  of eyes out there will tell us about the bugs and
  send in patches to fix them.

That last part is, of course, why Open Source is usually better.

| Actually, for a target type of install, the test/validation should be
| performed as part of the install procedure.

I've seen this done, but I'm not sure I like the idea.  Especially if
the  install needs to be done as root.  I don't think I like the idea
of the tests running as root.  Also, if a test  fails,  I'd  like  to
repeat  the "make test" after trying patches, without the prospect of
the install also being done. But combining test and install does save
novice users a bit of work, at least when nothing fails.

| ... Also, some applications don't lend themselves to scripted
| testing. An example would be a graphical email program.

This is certainly true.  Testing GUI code isn't what you'd call easy.
The  X  server  was designed to make it possible, and both tcl/tk and
perl/tk have a "make test" that are entertaining demos  of  the  fact
that it's possible.  But if you look at the code, you quickly realize
that this was probably harder than writing the tk package itself. You
are  going to spend a lot more than a weekend if you want to add such
a test suite to your own package.

Then there's the growing problem of debugging  things  that  interact
with  things  behind  a web server.  More and more things can only be
managed via a web interface.  I just got off the phone with a  friend
who  is  facing  a  real nightmare:  A web-based package that has the
ability to convert its proprietary files  to  postscript.   Those  PS
files  can  be  fed  to  converters and the useful information can be
extracted.  But they have over 15000 files, with more arriving daily.
Sitting at a computer trying to click the Print menus for 15000 items
is a deadly job, and highly error prone.  The  obvious  thing  is  to
automate  this.  But how do you automate a web interface?  Their best
bet so far has been to use script to record the keystrokes of a  lynx
session, and turn that into scripts.  But the package keeps coming up
with clever new web pages or interesting new variants  of  web  pages
that  aren't  covered  by their scripts.  And, of course, some of the
package's pieces refuse to talk to lynx.

I wonder if anyone has a webbified version of expect yet?  Is there a
version that talks to an X server?