[MERGE] Improve tests for the behaviour of Tree.iter_changes for missing paths that are only present in one tree, and fix found bugs. (Robert Collins)

John Arbash Meinel john at arbash-meinel.com
Thu Aug 14 03:52:39 BST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Bennetts wrote:
> Robert Collins wrote:
>> On Wed, 2008-08-13 at 09:17 -0500, John Arbash Meinel wrote:
> [...]
>>> BB:tweak
>>>
>>> I agree with Andrew about raising TestNotApplicable, even though it
>>> isn't your preference, it *is* the recommended way of doing it in the
>>> test suite.
>> How about:
>>  - I raise a bug saying that: our test parameterisation generates too
>> many tests, we need a easy way of having some permutations getting
>> opted-out (and that when that is done TNA gets deleted)
>>  - I raise TNA
> 
> I'm ok with this course of action.  (Although I'm not at all sure that *all*
> uses of TNA will be better if replaced with more complicated parameterisation,
> I'm happy to explore the possibility.)
> 
> In the meantime, TNA is the best we've got (better than a bare return).
> 
> -Andrew.
> 
> 

I *do* think that TNA is the best we have right now. It unwinds the stack, so
means you don't have to write:

if helper_says_i_cant_play():
  return

Mostly because the helper may call another helper, which calls deeper, and you
really want to return a WorkingTree object.

Also, because TNA can be raised during setUp() rather than decorating each
test with:

if self._setupfailed_because_of_tna:
  return

The good bad about not running the tests in the first place, is that it may
take a bit of set up before you really know if the test is available. The hope
is that you can do a minimal amount of work to realize it isn't. (Certainly,
we've had tests that do a bunch of build_tree, and commit, and then decide to
bail out, which always looks bad to see 1000ms taken up on a N/A test.)

But, badly written tests will get written, and they just need to be fixed.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIo533JdeBCYSNAAMRAkdRAKCzP5pAioGrVhgzlQg1EXEd6XB4NQCgvN37
eQ7jp6JAPAVBtOizM1mIZzU=
=bupo
-----END PGP SIGNATURE-----



More information about the bazaar mailing list