+1, Ben.
Ben Collins-Sussman writes:
> 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.
>
> The problem, Greg, is that our current C test framework is ideal for
> testing *library* routines, which is exactly how we're using it.
>
> The client test suite needs to test the svn binary from the
> *outside*... hence our need for a testing system written in an
> interpreted scripting language.
>
> > Certainly, I could see setting up a suite for one part, and migrating the
> > other over time. But long term? I'd think "one".
>
> Migrating the other? This means either using C to make system() calls
> to svn and then grepping through the SVN/ dirs (yuck), or it means
> using a scripting language to test internal library routines. (The
> latter would mean tossing the perfectly good C framework we have and
> then writing script wrappers around each library. What a crazy waste
> of work!)
>
> I'm really not following you here. C is ideal for internal testing,
> and scripts are ideal for external testing. Why mix apples and
> oranges?
>
>
> > 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?
>
> Perl (or Python) is just a happier, more friendly, more integrated
> environment for doing all the things that {sh, diff, cmp, awk, sed,
> ..} do.
>
> Here's an example:
>
> After telling svn to commit to XML, and then telling svn to update a
> -different- working copy from that same XML file, we should have two
> identical working copies. Of course, we need to do a lot of work to
> verify that; we'd want to read each `entries' file into a hash and the
> compare hashes. Isn't Perl or Python better suited for this than
> bash?
>
--
Lee P. W. Burgess <<!>> Manipulate eternity. Power is a symphony:
Programmer <<!>> elaborate, enormous, essential.
Red Bean Software <<!>> Dream the moment with a fiddle in summer
lefty@red-bean.com <<!>> and a knife in winter.
Received on Sat Oct 21 14:36:25 2006