Greg Stein <gstein@lyra.org> writes:
> I would like to see the same test suite / mechanism applied to both the
> client *and* the libraries. Using two mechanisms feels like a non-starter.
> Certainly, I could see setting up a suite for one part, and migrating the
> other over time. But long term? I'd think "one".
The trouble is that some tests test an executable (say, the client
binary), and others test C interfaces. Trying to use one mechanism
for both may be very difficult.
> Please explain this one. I don't see an issue with a bash script that runs
> the client in interesting ways, then compares the resulting output against a
> snapshot/template of the "correct" output. What more is there?
>
> diff, diff -r, and/or cmp can be used to compare output. sed can be used to
> replace (changing) timestamps with a fixed value before comparison. etc
>
> You obviously have some kind of function in mind that /bin/sh and some other
> tools can't handle. What were you thinking of?
>
> Note that I would also suggest "awk" for another card in your test suite
> deck. Awk is probably more common than Perl/Python/Tcl. I also know there
> are handy prebuilt awk.exe files floating around (we use it in Apache 2.0
> httpd for some stuff on Windows installation).
I agree that Bourne shell is functionally fine, and that a good test
suite could be written in it. The problem with Bourne is portability
to non-Unix systems, not the shell language itself.
> > A couple of issues to think about are portability and maintenance.
> > Portability is probably paramount.
>
> Shell tools, Perl, and Python are all quite portable. The question that came
> up over the past day is "availability" :-) All are quite available for "all"
> platforms, even though they may not be installed by default. I agree with
> the general sentiment of "it is optional end-user functionality, so we don't
> have to work overly hard to make it available for people." In that sense, a
> scripting language is fine with me, but I think that may be overkill
> relative to shell tools.
>
> Note that if you're talking about testing a separate executable, it is
> actually quite a bit easier / clearer to use /bin/sh rather than P*. For
> example:
If a compatible Bourne shell is available for Windows and Mac systems,
without requiring Cygwin, then I think we should stick with Bourne.
However, I wasn't aware of such availability... (?)
-K
Received on Sat Oct 21 14:36:25 2006