[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: subversion client test suite

From: Ben Collins-Sussman <sussman_at_newton.ch.collab.net>
Date: 2001-03-09 14:48:31 CET

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

> 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
Received on Sat Oct 21 14:36:25 2006

This is an archived mail posted to the Subversion Dev mailing list.