[rfc] cleaning up run_bzr and similar things in the test suite

[Robert Collins]

On Tue, 2007-06-26 at 08:34 -0500, John Arbash Meinel wrote:

> Martin Pool wrote:
> > Marius, and other people reviewing his work, reminded me that the
> ways
> > by which the test suite exercises the bzr command line are currently
> a
> > bit messy.  I am now cleaning them up and wanted to just give some
> > advance warning and let people object if they will.

I've just replied to Marius' email explaining my rationale for prefering
magic-less interfaces here. One thing that we haven't really discussed
is separating out the tests of the parsing vs the execution of command
logic.

e.g.
self.assertCommandParses(["add", "a", "b"], {paths:["a", "b"]})

and separately

cmd = cmd_add()
cmd.run(paths=["a", "b"])

to test the command logic.

I've been thinking for a bit this might be nice to do.

> > One question is how arguments should be passed:
> > 
> >  1- run_bzr("add a b")
> >  2- run_bzr(["add", "a", "b"])
> >  3- run_bzr("add", "a", "b")
> > 
> > 1 has the advantage that it's much easier to read and write but the
> > problem that it needs to be split.  2 is more reliable and avoids
> > quoting problems if you need to pass arguments containing
> > metacharacters, or which might do so, or if you need to mix in
> > variables, and is closer to the real interface of commands.py.  3
> > seems like an inferior compromise between the two.
> > 
> > Having looked at several of these I really prefer #1 in cases where
> > it's safe to use, and I would be happy to see it in new code. I'm
> > going to get rid of #3 when I see it.  Robert asks that it be at
> least
> > fairly explicit when and where the splitting is done.
> > 
> > But the main problem is just a multiplication of similar interfaces.
> > 
> 
> I actually prefer 3 to 2 because it is less typing for the same gain.
> I *think*
> you'll find it the most common.

OTOH it makes passing in parameters to control the execution complex at
best - my eyes bleed when looking at the definition of the *args,
**kwargs functions.

> Overall, 1 is quite a bit easier to type, and I guess 2 is only
> marginally
> harder than 3.
> 
> If you are getting into it, you should also be aware of all of the
> run_bzr_captured(), run_bzr(), capture(), ... I think there are a few
> more. All
> are fairly subtly different, and their differences should probably be
> unified.
> 
> I'm happy to conform to whatever standard we decide. But I thought I
> would make
> mention that I've been using 3 for quite some time. 

I prefer 2 because its clearer on kwarg parameters, and doesn't do
splitting so I never have to escape stuff.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070627/6c5f13db/attachment.pgp