Sam TH <sam@uchicago.edu> writes:
> We take a regular working copy. We modify the repository it's from
> via some other working copy. Then we update the working copy. We now
> have a number of representations of what happend.
>
> 1. The output of 'svn up'.
> 2. The expected changes.
> 3. The changes to the entries files.
> 4. The changes to the actual working copy.
>
> I really think that it's important that we verify that all of these
> are consistent.
Okay, now I understand your system. :)
It's basically a world based on a single standardized "diff tree".
You create "diff trees" based on the 4 situations above, and compare
them all to each other.
I understand that it has the advantage of potentially being more
thorough and maintainable, but at the disadvantage of being more
complex.
The deal is: the testing system I've been proposing is already done.
I can compare "wc trees" to static expected ones, and I can compare
"output trees" to static expected ones. That's *all I need* to write
the tests we so desperately need, so I'm going to stop searching for
the perfect design now.
I'm going to check in the existing system, and a bunch of tests that
use them. If you want to additionally implement your fancier system,
I say "all power to you". Submit patches; just don't destroy or
overwrite the existing system & tests.
We'll probably end up with two different API's for writing tests;
there's certainly nothing wrong with this. Let them both coexist and
be used. (It certainly doesn't hurt to do two different kinds of
testing!) If someday one of them bit-rots or proves unmaintainable,
we'll throw it out. :)
Received on Sat Oct 21 14:36:29 2006