From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Tue, 17 Apr 2012 06:32:29 GMT
Subject: Re: [PATCH v2] tests: add initial bash completion tests
Message-ID: <CAMP44s1CTCPThri6mq0NTvD27WTEiwLTfhHCw+nD+8YwApwL=g@mail.gmail.com>
In-Reply-To: <20120417003100.GB2299@goldbirke>

On Tue, Apr 17, 2012 at 3:31 AM, SZEDER Gábor <szeder@fzi.de> wrote:
> Hi,
>
>
> I picked up Stephen Boyd's two-patch series[1] to use parse-options to
> generate options for git commands, and the following test promply
> failed (taken from 5c293a6b (tests: add initial bash completion tests,
> 2012-04-12)):
>
> test_expect_success 'double dash "git checkout"' '
>        sed -e "s/Z$//" >expected <<-\EOF &&
>        --quiet Z
>        --ours Z
>        --theirs Z
>        --track Z
>        --no-track Z
>        --merge Z
>        --conflict=
>        --orphan Z
>        --patch Z
>        EOF
>        test_completion "git checkout --"
> '
>
> Not surprising, the completion script doesn't know about many 'git
> checkout' long options.  So whenever 'git checkout' learns a new long
> option, this list must be updated.  This won't be more work than the
> update of the completion script, so this is probably OK.
>
> But it got me thinking about what do we actually want to test here?
> Whether the completion script returns the right long options in a
> specific order upon 'git checkout --<TAB>'?  Or whether _git() works
> properly and invokes the right command-specific completion function?
> Or whether regular options get a trailing space while options
> expecting an argument don't?  Or is this sort of an integration test
> and basically all of the above?

I don't think the order is relevant, just that all the options are
there, and the ones with arguments have a = in there, and the ones
that don't, a space.

-- 
Felipe Contreras