[MERGE] Add support for previewing the result of a merge

[Andrew Bennetts]

John Arbash Meinel wrote:
> Aaron Bentley wrote:
[...]
> >>> +    def test_iter_changes(self):
> >>> +        revision_tree = self.create_tree()
> >>> +        root = revision_tree.inventory.root.file_id
> >>> +        preview = TransformPreview(revision_tree)
> >>> +        a_trans_id = preview.trans_id_file_id('a-id')
> >>> +        preview.delete_contents(a_trans_id)
> >>> +        preview.create_file('b content', a_trans_id)
> >>> +        preview_tree = preview.get_preview_tree()
> >>> +        self.assertEqual([('a-id', ('a', 'a'), True, (True, True),
> >>> +                          (root, root), ('a', 'a'), ('file', 'file'),
> >>> +                          (False, False))],
> >>> +                          list(preview_tree._iter_changes(revision_tree)))
> >>> +        # Test unsupported parameters
> >>> +        e = self.assertRaises(ValueError, preview_tree._iter_changes,
> >>> +                              preview_tree)
> >  
> >> ^- This seems like a test that you would really rather have as a set of
> >> tests, rather than one big conglomeration.
> > 
> > I don't agree.  It's all testing the same thing.  Having to build the
> > same fixture repeatedly just to test that a given option raises
> > ValueError seems like a waste of runtime to me.
> 
> I'll let the more test focused people (like Robert) chime in here. But
> my understanding is that all-in-one tests like this are brittle. It
> breaks in the middle, which doesn't show you if the rest is working or
> not. You get 1 test failure which might actually be 5 things that need
> to be fixed. Conversely if you are expecting side effects (not true in
> this case), you may get a false failure. (It failed because of the set
> up, but what you were actually testing in that test would have succeeded.)

I tend to agree with John here.  My motivation is more clarity than brittleness.
I find several short, very specific test methods are easier to understand than
one big test method that does several things.  This is especially true when the
time comes to add a test for another condition: with a conglomeration test
method it is hard to decide what the scope of it should be, and thus if a new
test ought to be part of the conglomeration or a new method.  Similarly, when
trying to get an overview of the existing tests by reading the code, I find it
easier if I can just skim for lots of “def test_this_condition” and “def
test_that_condition” rather than having to read a single large test method
itself in detail.

So I find single (narrow) purpose test methods easier to work with.  They also
force the author to think of a name for each condition, rather than just
sticking yet another assert in with no explanation.  (Although in this case
you've commented the various conditions quite well.)

-Andrew.