[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)

Andrew Bennetts andrew at canonical.com
Thu Aug 14 00:36:54 BST 2008


Robert Collins wrote:
> On Wed, 2008-08-13 at 17:14 +1000, Andrew Bennetts wrote:
[...]
> > Hmm, wouldn't raising TestNotApplicable be more appropriate than just returning?
> 
> TestNotApplicable, because its an exception, shows up as an error or
> failure in a downlevel test runner. That doesn't match what is going on
> here. (Or to put it another way, I don't like TestNotApplicable all that
> much, because 'raise' and 'not a problem' just don't fit in my head).

Well, “raise” and “abort what is currently happening” does fit in my head.  So
using the way our style guide TestNotApplicable makes sense to me.  It is an
“exception” in the sense that it is an exception to the regular case of the test
method running to completion.

Using “return” for this purpose certainly doesn't fit *my* head very well, and
has pragmatic drawbacks of being implicit and only possible in the test method
directly (raising an exception can be trivially extracted into a helper method).

If we are genuinely concerned about compatibility other test runners, it is
possible to change our TestCase to detect TestResults that aren't from
bzrlib.tests and adapt our behaviour (or write an adapter for stdlib TestResult
instances).  Twisted's Trial manages to do this for it's SkipTest and other
related extensions (so e.g. SkipTest is recorded as a success if it can't be
recorded as a skip).

-Andrew.




More information about the bazaar mailing list