threads / patch / 31563

patchMake test output coloring more intuitive

Subject: [PATCH] Make test output coloring more intuitive

## tl;dr

18 messages between Sep 17, 2012 and Nov 11, 2012. Diffs are folded; open one to read it.

replies: 17people: 5as markdown or json

Adam Spiers· Sep 17, 2012, 11:50 UTC · lore
1. Change the color of individual known breakages from bold green to
   bold yellow.  This seems more appropriate when considering the
   universal traffic lights coloring scheme, where green conveys the
   impression that everything's OK, and amber that something's not
   quite right.
2. Likewise, change the color of the summarized total number of known
   breakages from bold red to bold yellow to be less alarmist and more
   consistent with the above.
3. Change color of unexpectedly fixed known breakages to bold red.  An
   unexpectedly passing test indicates that the test is wrong or the
   semantics of the code being tested have changed.  Either way this
   is an error which is arguably as bad as a failing test, and as such
   is now counted in the totals too.
The end result of these changes is that:
  - red is _only_ used for things which have gone unexpectedly wrong:
    test failures, unexpected test passes, and failures with the
    framework,
  - yellow is _only_ used for known breakages, and
  - green is _only_ used for things which have gone to plan and
    require no further work to be done.
Signed-off-by: Adam Spiers <git@adamspiers.org>
---
 t/t0000-basic.sh |  7 ++++---
 t/test-lib.sh    | 13 ++++++++-----
 2 files changed, 12 insertions(+), 8 deletions(-)
 mode change 100644 => 100755 t/test-lib.sh
Show changes to 2 files +12 −8

t/t0000-basic.sh, t/test-lib.sh

diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index ae6a3f0..4e111b4 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -81,9 +81,10 @@ test_expect_success 'pretend we have fixed a known breakage (run in sub test-lib
 	./passing-todo.sh >out 2>err &&
 	! test -s err &&
 	sed -e 's/^> //' >expect <<-\\EOF &&
-	> ok 1 - pretend we have fixed a known breakage # TODO known breakage
-	> # fixed 1 known breakage(s)
-	> # passed all 1 test(s)
+	> ok 1 - pretend we have fixed a known breakage # TODO known breakage vanished
+	> # fixed 1 known breakage(s); please update test(s)
+	> # still have 1 known breakage(s)
+	> # passed all remaining 0 test(s)
 	> 1..1
 	EOF
 	test_cmp expect out)
diff --git a/t/test-lib.sh b/t/test-lib.sh
old mode 100644
new mode 100755
index f8e3733..9907035
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -183,10 +183,12 @@ then
 			tput bold; tput setaf 1;; # bold red
 		skip)
 			tput bold; tput setaf 2;; # bold green
+		warn)
+			tput bold; tput setaf 3;; # bold yellow
 		pass)
 			tput setaf 2;;            # green
 		info)
-			tput setaf 3;;            # brown
+			tput setaf 3;;            # yellow/brown
 		*)
 			test -n "$quiet" && return;;
 		esac
@@ -276,12 +278,13 @@ test_failure_ () {
 
 test_known_broken_ok_ () {
 	test_fixed=$(($test_fixed+1))
-	say_color "" "ok $test_count - $@ # TODO known breakage"
+	test_broken=$(($test_broken+1))
+	say_color error "ok $test_count - $@ # TODO known breakage vanished"
 }
 
 test_known_broken_failure_ () {
 	test_broken=$(($test_broken+1))
-	say_color skip "not ok $test_count - $@ # TODO known breakage"
+	say_color warn "not ok $test_count - $@ # TODO known breakage"
 }
 
 test_debug () {
@@ -371,11 +374,11 @@ test_done () {
 
 	if test "$test_fixed" != 0
 	then
-		say_color pass "# fixed $test_fixed known breakage(s)"
+		say_color error "# fixed $test_fixed known breakage(s); please update test(s)"
 	fi
 	if test "$test_broken" != 0
 	then
-		say_color error "# still have $test_broken known breakage(s)"
+		say_color warn "# still have $test_broken known breakage(s)"
 		msg="remaining $(($test_count-$test_broken)) test(s)"
 	else
 		msg="$test_count test(s)"
-- 
1.7.12.147.g6d168f4
Jeff King· Sep 17, 2012, 20:11 UTC · re: Adam Spiers · lore

Re: [PATCH] Make test output coloring more intuitive

On Mon, Sep 17, 2012 at 12:50:37PM +0100, Adam Spiers wrote:
Show 10 quoted lines
> The end result of these changes is that:
> 
>   - red is _only_ used for things which have gone unexpectedly wrong:
>     test failures, unexpected test passes, and failures with the
>     framework,
> 
>   - yellow is _only_ used for known breakages, and
> 
>   - green is _only_ used for things which have gone to plan and
>     require no further work to be done.

Sounds reasonable, and I think the new output looks nice. I notice that skipped tests are still in green. I wonder if they should be in yellow, too. They may or may not be a problem, but you are failing to run some portion of the test suite.

Show 18 quoted lines
> diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
> index ae6a3f0..4e111b4 100755
> --- a/t/t0000-basic.sh
> +++ b/t/t0000-basic.sh
> @@ -81,9 +81,10 @@ test_expect_success 'pretend we have fixed a known breakage (run in sub test-lib
>  	./passing-todo.sh >out 2>err &&
>  	! test -s err &&
>  	sed -e 's/^> //' >expect <<-\\EOF &&
> -	> ok 1 - pretend we have fixed a known breakage # TODO known breakage
> -	> # fixed 1 known breakage(s)
> -	> # passed all 1 test(s)
> +	> ok 1 - pretend we have fixed a known breakage # TODO known breakage vanished
> +	> # fixed 1 known breakage(s); please update test(s)
> +	> # still have 1 known breakage(s)
> +	> # passed all remaining 0 test(s)
>  	> 1..1
>  	EOF
>  	test_cmp expect out)

This hunk is surprising after reading the commit message. It looks like you are also breaking down expect_fail tests by fixed and not fixed.

I think that is probably an OK thing to do (although it might make more sense in a separate patch), but are your numbers right? It looks from that count as if there are 2 tests expecting failure (one fixed and one still broken).

-Peff
Adam Spiers· Sep 18, 2012, 21:21 UTC · re: Jeff King · lore

Re: [PATCH] Make test output coloring more intuitive

On Mon, Sep 17, 2012 at 04:11:19PM -0400, Jeff King wrote:
Show 17 quoted lines
> On Mon, Sep 17, 2012 at 12:50:37PM +0100, Adam Spiers wrote:
> 
> > The end result of these changes is that:
> > 
> >   - red is _only_ used for things which have gone unexpectedly wrong:
> >     test failures, unexpected test passes, and failures with the
> >     framework,
> > 
> >   - yellow is _only_ used for known breakages, and
> > 
> >   - green is _only_ used for things which have gone to plan and
> >     require no further work to be done.
> 
> Sounds reasonable, and I think the new output looks nice. I notice that
> skipped tests are still in green. I wonder if they should be in yellow,
> too. They may or may not be a problem, but you are failing to run some
> portion of the test suite.

Fair point, I'll reroll the series and change skipped tests to yellow (non-bold, to distinguish from known breakages which are bold yellow).

Show 21 quoted lines
> > diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
> > index ae6a3f0..4e111b4 100755
> > --- a/t/t0000-basic.sh
> > +++ b/t/t0000-basic.sh
> > @@ -81,9 +81,10 @@ test_expect_success 'pretend we have fixed a known breakage (run in sub test-lib
> >  	./passing-todo.sh >out 2>err &&
> >  	! test -s err &&
> >  	sed -e 's/^> //' >expect <<-\\EOF &&
> > -	> ok 1 - pretend we have fixed a known breakage # TODO known breakage
> > -	> # fixed 1 known breakage(s)
> > -	> # passed all 1 test(s)
> > +	> ok 1 - pretend we have fixed a known breakage # TODO known breakage vanished
> > +	> # fixed 1 known breakage(s); please update test(s)
> > +	> # still have 1 known breakage(s)
> > +	> # passed all remaining 0 test(s)
> >  	> 1..1
> >  	EOF
> >  	test_cmp expect out)
> 
> This hunk is surprising after reading the commit message. It looks like
> you are also breaking down expect_fail tests by fixed and not fixed.
Correct.
> I think that is probably an OK thing to do (although it might make more
> sense in a separate patch), but are your numbers right?

They are right (at least as I intended), but I agree it's a bit confusing.

> It looks from that count as if there are 2 tests expecting failure
> (one fixed and one still broken).

It's actually one test which is both fixed *and* in some sense broken. The confusion arises from the ambiguity of the word "broken", which could mean either "failed as expected" or "expected to fail but didn't". Previously it was just the former, but my patch changed it to encompass both cases. The motivation behind this was to avoid the

    # passed all $count test(s)

summary message which is overly comforting when one or more tests were expected to fail but didn't. However perhaps it's cleaner to keep the counter buckets separated. I'll try to come up with a better solution.

Stefano Lattarini· Sep 19, 2012, 20:02 UTC · re: Jeff King · lore

Re: [PATCH] Make test output coloring more intuitive

On 09/17/2012 10:11 PM, Jeff King wrote:
Show 17 quoted lines
> On Mon, Sep 17, 2012 at 12:50:37PM +0100, Adam Spiers wrote:
> 
>> The end result of these changes is that:
>>
>>   - red is _only_ used for things which have gone unexpectedly wrong:
>>     test failures, unexpected test passes, and failures with the
>>     framework,
>>
>>   - yellow is _only_ used for known breakages, and
>>
>>   - green is _only_ used for things which have gone to plan and
>>     require no further work to be done.
> 
> Sounds reasonable, and I think the new output looks nice. I notice that
> skipped tests are still in green. I wonder if they should be in yellow,
> too.
>
What about blue instead?   This would keep the colouring scheme more
consistent with the one used by prove:
  <http://search.cpan.org/~ovid/Test-Harness/bin/prove>
by autotest:
  <http://www.gnu.org/software/autoconf/manual/autoconf.html#Using-Autotest>
and by the Automake-generated test harness:
  <http://www.gnu.org/software/automake/manual/automake.html#Scripts_002dbased-Testsuites>
Just my 2 cents,
  Stefano
Adam Spiers· Sep 19, 2012, 20:12 UTC · re: Stefano Lattarini · lore

Re: [PATCH] Make test output coloring more intuitive

On Wed, Sep 19, 2012 at 10:02:52PM +0200, Stefano Lattarini wrote:
Show 25 quoted lines
> On 09/17/2012 10:11 PM, Jeff King wrote:
> > On Mon, Sep 17, 2012 at 12:50:37PM +0100, Adam Spiers wrote:
> > 
> >> The end result of these changes is that:
> >>
> >>   - red is _only_ used for things which have gone unexpectedly wrong:
> >>     test failures, unexpected test passes, and failures with the
> >>     framework,
> >>
> >>   - yellow is _only_ used for known breakages, and
> >>
> >>   - green is _only_ used for things which have gone to plan and
> >>     require no further work to be done.
> > 
> > Sounds reasonable, and I think the new output looks nice. I notice that
> > skipped tests are still in green. I wonder if they should be in yellow,
> > too.
> >
> What about blue instead?   This would keep the colouring scheme more
> consistent with the one used by prove:
>   <http://search.cpan.org/~ovid/Test-Harness/bin/prove>
> by autotest:
>   <http://www.gnu.org/software/autoconf/manual/autoconf.html#Using-Autotest>
> and by the Automake-generated test harness:
>   <http://www.gnu.org/software/automake/manual/automake.html#Scripts_002dbased-Testsuites>

Sounds good to me! Blue is the conventional color for informational signs, so seems like a natural fit for skipped tests. Not sure whether it should be bold or not though? I'll wait for a more solid group consensus before re-rolling yet another patch :-)

Jeff King· Sep 19, 2012, 20:13 UTC · re: Adam Spiers · lore

Re: [PATCH] Make test output coloring more intuitive

On Wed, Sep 19, 2012 at 09:12:01PM +0100, Adam Spiers wrote:
Show 16 quoted lines
> > > Sounds reasonable, and I think the new output looks nice. I notice that
> > > skipped tests are still in green. I wonder if they should be in yellow,
> > > too.
> > >
> > What about blue instead?   This would keep the colouring scheme more
> > consistent with the one used by prove:
> >   <http://search.cpan.org/~ovid/Test-Harness/bin/prove>
> > by autotest:
> >   <http://www.gnu.org/software/autoconf/manual/autoconf.html#Using-Autotest>
> > and by the Automake-generated test harness:
> >   <http://www.gnu.org/software/automake/manual/automake.html#Scripts_002dbased-Testsuites>
> 
> Sounds good to me!  Blue is the conventional color for informational
> signs, so seems like a natural fit for skipped tests.  Not sure
> whether it should be bold or not though?  I'll wait for a more solid
> group consensus before re-rolling yet another patch :-)

Blue would be fine with me. No strong opinion on bold or not (my gut is that most things should not be bold unless there is a good reason, but that is just a feeling).

-Peff
Adam Spiers· Sep 19, 2012, 20:24 UTC · re: Jeff King · lore

[PATCH v4 3/6] Color skipped tests blue

Skipped tests indicate incomplete test coverage. Whilst this is not a test failure or other error, it's still not complete success, so according to the universal traffic lights coloring scheme, yellow/brown seems more suitable than green. However, it's more informational than cautionary, so instead we use blue which is a universal color for information signs.

Signed-off-by: Adam Spiers <git@adamspiers.org>
---
 t/test-lib.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Show changes to t/test-lib.sh +2 −2
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 5293830..78c88c2 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -182,13 +182,13 @@ then
 		error)
 			tput bold; tput setaf 1;; # bold red
 		skip)
-			tput bold; tput setaf 2;; # bold green
+			tput setaf 4;;            # blue
 		warn)
 			tput bold; tput setaf 3;; # bold yellow
 		pass)
 			tput setaf 2;;            # green
 		info)
-			tput setaf 3;;            # brown
+			tput setaf 3;;            # yellow/brown
 		*)
 			test -n "$quiet" && return;;
 		esac
-- 
1.7.12.147.g6d168f4
Johannes Sixt· Sep 20, 2012, 05:48 UTC · re: Adam Spiers · lore

Re: [PATCH v4 3/6] Color skipped tests blue

Am 9/19/2012 22:24, schrieb Adam Spiers:
>  		skip)
> -			tput bold; tput setaf 2;; # bold green
> +			tput setaf 4;;            # blue

It's unreadable on black background. Keep it bold; that works on both black and white background.

-- Hannes
Adam Spiers· Sep 20, 2012, 09:04 UTC · re: Johannes Sixt · lore

Re: [PATCH v4 3/6] Color skipped tests blue

On Thu, Sep 20, 2012 at 6:48 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
Show 7 quoted lines
> Am 9/19/2012 22:24, schrieb Adam Spiers:
>>               skip)
>> -                     tput bold; tput setaf 2;; # bold green
>> +                     tput setaf 4;;            # blue
>
> It's unreadable on black background. Keep it bold; that works on both
> black and white background.

Whilst my preference aligns with yours in this particular case, we are now on a slippery slope, since these days terminal colors are infinitely configurable, and some heretics even choose backgrounds which are neither black nor white ;-) I don't want to trigger a long discussion or end up spamming the list with lots of different color scheme patches in an attempt to please everyone. So bold blue will be my last version of this patch.

Adam Spiers· Sep 20, 2012, 09:08 UTC · re: Johannes Sixt · lore

[PATCH v5 3/3] Color skipped tests bold blue

Skipped tests indicate incomplete test coverage. Whilst this is not a test failure or other error, it's still not complete success, so according to the universal traffic lights coloring scheme, yellow/brown seems more suitable than green. However, it's more informational than cautionary, so instead we use blue which is a universal color for information signs. Bold blue should work better on both black and white backgrounds than normal blue.

Signed-off-by: Adam Spiers <git@adamspiers.org>
---
 t/test-lib.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Show changes to t/test-lib.sh +2 −2
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 5293830..5ef87d4 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -182,13 +182,13 @@ then
 		error)
 			tput bold; tput setaf 1;; # bold red
 		skip)
-			tput bold; tput setaf 2;; # bold green
+			tput bold; tput setaf 4;; # bold blue
 		warn)
 			tput bold; tput setaf 3;; # bold yellow
 		pass)
 			tput setaf 2;;            # green
 		info)
-			tput setaf 3;;            # brown
+			tput setaf 3;;            # yellow/brown
 		*)
 			test -n "$quiet" && return;;
 		esac
-- 
1.7.12.147.g6d168f4
Stefano Lattarini· Sep 20, 2012, 10:08 UTC · re: Adam Spiers · lore

Re: [PATCH v5 3/3] Color skipped tests bold blue

Hi Adam.
On 09/20/2012 11:08 AM, Adam Spiers wrote:
Show 9 quoted lines
> Skipped tests indicate incomplete test coverage.  Whilst this is
> not a test failure or other error, it's still not complete
> success, so according to the universal traffic lights coloring
> scheme, yellow/brown seems more suitable than green.  However,
> it's more informational than cautionary, so instead we use blue
> which is a universal color for information signs.  Bold blue
> should work better on both black and white backgrounds than
> normal blue.
>

A very minor nit (feel free to ignore it): IMHO, it should be nice to state explicitly in the commit message that blue is already used by other testsuite-related software to highlight skipped tests; you can report the examples of at least Automake, Autotest and prove -- and extra kudos if you find further examples ;-)

Thanks,
  Stefano
Junio C Hamano· Sep 20, 2012, 16:20 UTC · re: Stefano Lattarini · lore

Re: [PATCH v5 3/3] Color skipped tests bold blue

Stefano Lattarini <stefano.lattarini@gmail.com> writes:
Show 17 quoted lines
> Hi Adam.
>
> On 09/20/2012 11:08 AM, Adam Spiers wrote:
>> Skipped tests indicate incomplete test coverage.  Whilst this is
>> not a test failure or other error, it's still not complete
>> success, so according to the universal traffic lights coloring
>> scheme, yellow/brown seems more suitable than green.  However,
>> it's more informational than cautionary, so instead we use blue
>> which is a universal color for information signs.  Bold blue
>> should work better on both black and white backgrounds than
>> normal blue.
>>
> A very minor nit (feel free to ignore it): IMHO, it should be nice
> to state explicitly in the commit message that blue is already used
> by other testsuite-related software to highlight skipped tests; you
> can report the examples of at least Automake, Autotest and prove --
> and extra kudos if you find further examples ;-)

Thanks. Will tweak the proposed log message to include the above when queuing the updated patch.

Jeff King· Sep 21, 2012, 06:13 UTC · re: Adam Spiers · lore

Re: [PATCH v4 3/6] Color skipped tests blue

On Wed, Sep 19, 2012 at 09:24:23PM +0100, Adam Spiers wrote:
Show 20 quoted lines
>  t/test-lib.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 5293830..78c88c2 100755
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -182,13 +182,13 @@ then
>  		error)
>  			tput bold; tput setaf 1;; # bold red
>  		skip)
> -			tput bold; tput setaf 2;; # bold green
> +			tput setaf 4;;            # blue
>  		warn)
>  			tput bold; tput setaf 3;; # bold yellow
>  		pass)
>  			tput setaf 2;;            # green
>  		info)
> -			tput setaf 3;;            # brown
> +			tput setaf 3;;            # yellow/brown

I happened to be running a test script with "-v" earlier today, and I noticed that the "expecting success..." dump of the test contents is also yellow. By your new rules, shouldn't it be blue?

I think it is matching the "info" type, which from the discussion should be blue, no?

Maybe it is just my terminal. I see it is labeled as "brown" here, but it looks very yellow (and I am using the stock xterm colors. According to:

  https://en.wikipedia.org/wiki/ANSI_colors

It looks it really is brown on some platforms. I'm not sure if it is worth worrying about. I don't really want to get into configurable colors just for the test-suite output.

-Peff
Adam Spiers· Nov 11, 2012, 02:04 UTC · re: Jeff King · lore

Re: [PATCH v4 3/6] Color skipped tests blue

On Fri, Sep 21, 2012 at 02:13:25AM -0400, Jeff King wrote:
Show 29 quoted lines
> On Wed, Sep 19, 2012 at 09:24:23PM +0100, Adam Spiers wrote:
> 
> >  t/test-lib.sh | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/t/test-lib.sh b/t/test-lib.sh
> > index 5293830..78c88c2 100755
> > --- a/t/test-lib.sh
> > +++ b/t/test-lib.sh
> > @@ -182,13 +182,13 @@ then
> >  		error)
> >  			tput bold; tput setaf 1;; # bold red
> >  		skip)
> > -			tput bold; tput setaf 2;; # bold green
> > +			tput setaf 4;;            # blue
> >  		warn)
> >  			tput bold; tput setaf 3;; # bold yellow
> >  		pass)
> >  			tput setaf 2;;            # green
> >  		info)
> > -			tput setaf 3;;            # brown
> > +			tput setaf 3;;            # yellow/brown
> 
> I happened to be running a test script with "-v" earlier today, and I
> noticed that the "expecting success..." dump of the test contents is
> also yellow. By your new rules, shouldn't it be blue?
> 
> I think it is matching the "info" type, which from the discussion should
> be blue, no?
It uses the "default" colour:
    say >&3 "expecting success: $2"
where say is defined:
    say () {
            say_color info "$*"
    }

Many other messages are output in this default colour too, and I never proposed to change it. The only time in the discussion where blue was associated with "info" was in this sentence I wrote in the commit message for the patch altering the colour of "skip" messages:

   "However, it's more informational than cautionary, so instead we
    use blue which is a universal color for information signs."

Whilst it could also be applied to "info", I don't think it would be a good idea to have the "skip" and "info" colours *both* as bold blue. It seems to me more important that the "skip" messages should visually stand out more than "info", since they are rarer and a more notable level of information than the latter (especially if --verbose is used). Additionally, yellow is already somewhat overloaded (yellow for "info" and bold yellow for "warn"). Therefore I would suggest changing "info" to perhaps bold white or bold cyan. Or "skip" could be magenta and "info" blue. But now we are heading down a slippery slope; it'll be near impossible to please everyone. Any final thoughts?

Show 7 quoted lines
> Maybe it is just my terminal. I see it is labeled as "brown" here, but
> it looks very yellow (and I am using the stock xterm colors. According
> to:
> 
>   https://en.wikipedia.org/wiki/ANSI_colors
> 
> It looks it really is brown on some platforms.
Yes, it can be.
> I'm not sure if it is
> worth worrying about.  I don't really want to get into configurable
> colors just for the test-suite output.

Agreed. There is no indisputably correct combination. However, I think that, modulo a tweak for the above, we are definitely in the right ball park. The main thing is that the traffic light colour scheme is adhered to, and that different types of message are clearly visually separated, with more important ones standing out more than less important ones.

Junio C Hamano· Sep 17, 2012, 20:50 UTC · re: Adam Spiers · lore

Re: [PATCH] Make test output coloring more intuitive

Adam Spiers <git@adamspiers.org> writes:
Show 15 quoted lines
> 1. Change the color of individual known breakages from bold green to
>    bold yellow.  This seems more appropriate when considering the
>    universal traffic lights coloring scheme, where green conveys the
>    impression that everything's OK, and amber that something's not
>    quite right.
>
> 2. Likewise, change the color of the summarized total number of known
>    breakages from bold red to bold yellow to be less alarmist and more
>    consistent with the above.
>
> 3. Change color of unexpectedly fixed known breakages to bold red.  An
>    unexpectedly passing test indicates that the test is wrong or the
>    semantics of the code being tested have changed.  Either way this
>    is an error which is arguably as bad as a failing test, and as such
>    is now counted in the totals too.
I agree with Peff's comments.

The point #3 above wants to be a separate patch; we may even want to consider a follow-up change to add an option to make a "test that is expected to fail did not fail" case a failure.

Show 6 quoted lines
>  test_known_broken_ok_ () {
>  	test_fixed=$(($test_fixed+1))
> -	say_color "" "ok $test_count - $@ # TODO known breakage"
> +	test_broken=$(($test_broken+1))
> +	say_color error "ok $test_count - $@ # TODO known breakage vanished"
>  }

Also I wonder if this is still a "TODO". "# TODO fixed known breakage", meaning that it is something that must be looked at by whoever happened to have fixed the known breakage by accident, might be a better wording.

Adam Spiers· Sep 18, 2012, 21:36 UTC · re: Junio C Hamano · lore

Re: [PATCH] Make test output coloring more intuitive

On Mon, Sep 17, 2012 at 01:50:39PM -0700, Junio C Hamano wrote:
Show 21 quoted lines
> Adam Spiers <git@adamspiers.org> writes:
> 
> > 1. Change the color of individual known breakages from bold green to
> >    bold yellow.  This seems more appropriate when considering the
> >    universal traffic lights coloring scheme, where green conveys the
> >    impression that everything's OK, and amber that something's not
> >    quite right.
> >
> > 2. Likewise, change the color of the summarized total number of known
> >    breakages from bold red to bold yellow to be less alarmist and more
> >    consistent with the above.
> >
> > 3. Change color of unexpectedly fixed known breakages to bold red.  An
> >    unexpectedly passing test indicates that the test is wrong or the
> >    semantics of the code being tested have changed.  Either way this
> >    is an error which is arguably as bad as a failing test, and as such
> >    is now counted in the totals too.
> 
> I agree with Peff's comments.
> 
> The point #3 above wants to be a separate patch;
OK, re-rolling this.
> we may even want to consider a follow-up change to add an option to
> make a "test that is expected to fail did not fail" case a failure.
Sounds like a nice idea.
Show 8 quoted lines
> >  test_known_broken_ok_ () {
> >  	test_fixed=$(($test_fixed+1))
> > -	say_color "" "ok $test_count - $@ # TODO known breakage"
> > +	test_broken=$(($test_broken+1))
> > +	say_color error "ok $test_count - $@ # TODO known breakage vanished"
> >  }
> 
> Also I wonder if this is still a "TODO".

Hah, I should trust my first instincts more; my first version of the patch dropped the "TODO", but then I put it back in because I thought people would object :-)

> "# TODO fixed known breakage", meaning that it is something that
> must be looked at by whoever happened to have fixed the known
> breakage by accident, might be a better wording.

I would challenge the assumption that the test passed because someone deliberately fixed the code it was testing. Whilst this is a probable scenario (e.g. if they forgot to adjust the test to expect success rather than failure), it's not the only one. Tests can be brittle and depend on external factors which can change unexpectedly. For example, I noticed that the final 'general options plus command' test in t9902-completion.sh is currently dependent on the contents of the current $PATH. This is because I have a shell-script called `git-check-email' on mine, so `check-email' becomes an extra subcommand completion possibility for the prefix `check'. Almost every other developer running this test would not encounter the same failure. It's not a huge stretch to imagine a similar corner case which could unexpectedly cause a test to pass when failure was expected.

Therefore I would suggest a wording which avoids implying that something was deliberately fixed. That was my reasoning behind introducing the word "vanished" to the output.

Jeff King· Sep 18, 2012, 21:59 UTC · re: Adam Spiers · lore

Re: [PATCH] Make test output coloring more intuitive

On Tue, Sep 18, 2012 at 10:36:17PM +0100, Adam Spiers wrote:
Show 8 quoted lines
> > > +	say_color error "ok $test_count - $@ # TODO known breakage vanished"
> > >  }
> > 
> > Also I wonder if this is still a "TODO".
> 
> Hah, I should trust my first instincts more; my first version of the
> patch dropped the "TODO", but then I put it back in because I thought
> people would object :-)

TODO is a special token[1] respected by TAP harnesses like "prove". I'm not sure what practical impact it has, but it should probably remain.

-Peff
[1] http://testanything.org/wiki/index.php/TAP_specification#TODO_tests
Adam Spiers· Sep 18, 2012, 22:14 UTC · re: Jeff King · lore

Re: [PATCH] Make test output coloring more intuitive

On Tue, Sep 18, 2012 at 10:59 PM, Jeff King <peff@peff.net> wrote:
Show 6 quoted lines
> TODO is a special token[1] respected by TAP harnesses like "prove". I'm
> not sure what practical impact it has, but it should probably remain.
>
> -Peff
>
> [1] http://testanything.org/wiki/index.php/TAP_specification#TODO_tests

Thanks, I didn't know that. For reasons I just stated elsewhere in this thread, I don't _completely_ agree with the specification where it says:

    "Should a todo test point begin succeeding, the harness should
    report it as a bonus.  This indicates that whatever you were
    supposed to do has been done and you should promote this to a
    normal test point."

However those semantics are well-defined enough to warrant keeping the "TODO" as you suggest.

← back to recent threads