[PATCH] issue1610: Add tests for convert's topological sort algorithm

[Patrick Mézard]

Greg Ward a écrit :
> On Sat, Apr 18, 2009 at 12:14 AM, Nicolas Dumazet <nicdumz at gmail.com> wrote:
>> 2009/4/18 Greg Ward <greg-hg at gerg.ca>
>>> +Ran 7 tests in 0.003s
>> The output should probably not include the time. Chances are that the
>> runtime will vary, depending on the hardware and load.
> 
> D'ohhh!  I totally missed that.  I was focusing entirely on the tests
> themselves, naturally.  I suspect the right thing to do is override
> and/or monkey patch unittest so it's more amenable to Mercurial tests:
> only write to stdout, don't print the time, etc.

http://www.selenic.com/mercurial/bts/issue1437
 
> But that brings up a good point... from grep'ing the existing tests,
> it looks like there are no PyUnit-based tests in Mercurial so far.  Is
> there a reason for that?  Or just historical accident, i.e. no one has
> gotten around to writing any?  I'm a huge slobbering fan of unit
> tests, and I'd rather use the framework in the standard library than
> invent a new one for every project.

Functional tests as we do them proved to be good enough:
- They are self documenting. It's easy to see what they are testing, easy to fix/update.
- They are easy to write (good for contributions), no need to know unit test frameworks, and usually easier to setup than unit tests
- Being forced to exhibit behaviours without digging code internals has a good effect on code design and instrumentation. It makes it easier to diagnose problems since there are usually visible side-effects.

That said, unit tests also have good properties, like being usually faster to run. I think there are places where it's worth using them. In your case though, I think you can easily test the topological ordering properties by running convert on well crafted mercurial repositories. And it can be done efficiently by providing a test bundle as well as the script generating it and load it in the test to avoid repository setup slowdown.

--
Patrick Mézard