Re: [PATCH v14 3/6] t0040-parse-options: improve test coverage
- From
Pranit Bauva <pranit.bauva@gmail.com>
- Date
- Apr 13, 2016, 08:59 UTC
- Message-ID
- <CAFZEwPMU5KSoBJ0kHGnnPCq0zsoj8ROAXhJ9HFn66fqDehvWGw@mail.gmail.com>
- In-Reply-To
- <CAPig+cTB=bYNxR8yN2CGvkmtCZKomnbdNnZon9HA5uE9aivW=Q@mail.gmail.com>
On Wed, Apr 13, 2016 at 10:56 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 34 quoted lines
> On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote: >> Include tests to check for multiple levels of quiet and to check if the >> '--no-quiet' option sets it to 0. >> >> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> >> --- >> diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh >> @@ -476,4 +476,41 @@ test_expect_success '--no-list resets list' ' >> +cat >expect <<\EOF >> +boolean: 0 >> +integer: 0 >> +magnitude: 0 >> +timestamp: 0 >> +string: (not set) >> +abbrev: 7 >> +verbose: 0 >> +quiet: 0 >> +dry run: no >> +file: (not set) >> +EOF >> + >> +test_expect_success '--no-quiet sets quiet to 0' ' >> + test-parse-options --no-quiet >output 2>output.err && > > Meh, as implemented, this isn't a very interesting test, is it? > 'quiet' started at 0, so all this shows is that --no-quiet didn't > disturb the 0. To really test that it resets it to 0, you'd want: > > test-parse-options --quiet --no-quiet >... 2>... && > >> + test_must_be_empty output.err && >> + test_cmp expect output >> +' >> test_done
This is to test whether the 0 of quiet remains 0 if --no-quiet is included. This test "defines" the current behavior. Then when I change OPT_COUNTUP(), this test will ensure that this behavior is not interrupted as promised by the commit message of that patch[1]. I guess this also describe why I choose to include these tests between 2/5 and 3/5 rather than 3/5 and 4/5. And also see the extended discussion[2] for this. If I do a re-roll then I include `--quiet` before `--no-quiet`
[1]: http://article.gmane.org/gmane.comp.version-control.git/291313