Technical question about dirstate.statwalk

[Matt Mackall]

On Tue, 2008-05-20 at 13:06 +0200, Patrick Mézard wrote:
> Paul Moore a écrit :
> > 2008/5/20 Benoit Boissinot <bboissin at gmail.com>:
> > I'd love it if the test suite was migrated to a unittest-based
> > portable set of tests, but that's a pretty huge job, and not one I
> > expect to be able to tackle soon, so I just have to live with things
> > as they are at the moment...
> 
> Executable python scripts can be run by the test suite, there are a couple of them already. Having unittest-based tests if fine for me.

Yep, we can do that today (and several tests do go this route). But
converting everything to unit tests doesn't make a whole lot of sense. 

Unit tests have a few big downsides. The first is that they're harder to
write. Right now, anyone can write a test for the merge code without
even peeking at the source. And this is often how we get our tests.
Writing equivalent tests for merge.merge() would in fact be quite tricky
and would require intimate familiarity with lots of data structures.

Secondly, unit tests rarely survive refactoring. Even if a unit test for
the merge code had been written, we probably would have had to throw it
out twice by now. And if you're rewriting your test when you're
rewriting your code, you can no longer use it to spot regressions! By
comparison, we've got merge tests from the initial introduction of the
test suite that are still generating the same results as they used to.

Unit tests are great for simple, stable interfaces. Which make them a
good idea for things like the Python library, but not so much for us.
Many of our interfaces are not simple (they involve entire
repositories), and some are not stable (ie all the walk and interfaces
that just changed).

Unit tests are also good for building code in a vacuum when you can't do
a 'holistic test'. Which IMO is a horrible way to build code in the
first place.

-- 
Mathematics is the supreme nostalgia of our time.