From: Stefano Brivio <sbrivio@redhat.com>
To: David Ahern <dsahern@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
Sabrina Dubroca <sd@queasysnail.net>,
Steffen Klassert <steffen.klassert@secunet.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next 3/9] selftests: pmtu: Introduce support for multiple tests
Date: Fri, 16 Mar 2018 21:03:20 +0100 [thread overview]
Message-ID: <20180316210320.48a1b17e@epycfail> (raw)
In-Reply-To: <626b0eb0-846a-b00e-58a2-d5c2e3b24a95@gmail.com>
On Fri, 16 Mar 2018 12:53:23 -0700
David Ahern <dsahern@gmail.com> wrote:
> On 3/16/18 12:29 PM, Stefano Brivio wrote:
> > This might be equally counter-intuitive for somebody. If one does a lot
> > of explicit error checking with early returns, my return convention is
> > also rather practical. E.g. in the setup() function I can do:
> >
> > eval setup_${arg} && echo " ${arg} not supported" && return 0
> >
> > instead of:
> >
> > eval setup_${arg} || { echo " ${arg} not supported" && return 0; }
>
> I think it is weird to have 'a && b' where b is done when a fails as
> opposed to succeeds hence the comment. I think a common convention
> across scripts is important but having the tests is more so. Just a
> suggestion.
Yeah, also true. I'll change this.
> Look at fib_tests and fib-onlink-tests. As the number of tests grows,
> output consistency makes your life easier. With printf:
>
> ...
> TEST: IPv4 linkdown flag set [ OK ]
> TEST: IPv6 linkdown flag set [ OK ]
> TEST: Directly connected nexthop, unicast address [ OK ]
> TEST: Directly connected nexthop, unicast address with device [ OK ]
> TEST: Gateway is linklocal address [ OK ]
> TEST: Gateway is linklocal address, no device [ OK ]
> TEST: Gateway can not be local unicast address [ OK ]
> TEST: Gateway can not be local unicast address, with device [ OK ]
> TEST: Gateway can not be a local linklocal address [ OK ]
> TEST: Gateway can be local address in a VRF [FAIL]
> TEST: Gateway can be local address in a VRF, with device [FAIL]
> TEST: Gateway can be local linklocal address in a VRF [ OK ]
> TEST: Redirect to VRF lookup [ OK ]
> ...
>
> the FAIL cases jump out versus echo
>
> ...
> TEST: IPv4 linkdown flag set [ OK ]
> TEST: IPv6 linkdown flag set [ OK ]
> TEST: Directly connected nexthop, unicast address [ OK ]
> TEST: Directly connected nexthop, unicast address with device [ OK ]
> TEST: Gateway is linklocal address [ OK ]
> TEST: Gateway is linklocal address, no device [ OK ]
> TEST: Gateway can not be local unicast address [ OK ]
> TEST: Gateway can not be local unicast address, with device [ OK ]
> TEST: Gateway can not be a local linklocal address [ OK ]
> TEST: Gateway can be local address in a VRF [FAIL]
> TEST: Gateway can be local address in a VRF, with device [FAIL]
> TEST: Gateway can be local linklocal address in a VRF [ OK ]
> TEST: Redirect to VRF lookup [ OK ]
> ...
>
> where your mind has a lot more work to do to find the tests broken by a
> change.
>
> That is also why I chose OK versus PASS -- ok at 2 letters, fail at 4
> the failures really stand out.
I see your point. I'll use printf and make it a bit prettier in v2.
--
Stefano
next prev parent reply other threads:[~2018-03-16 20:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-15 16:18 [PATCH net-next 0/9] selftests: pmtu: Add further vti/vti6 MTU and PMTU tests Stefano Brivio
2018-03-15 16:18 ` [PATCH net-next 1/9] selftests: pmtu: Use namespace command prefix to fetch route mtu Stefano Brivio
2018-03-15 16:18 ` [PATCH net-next 2/9] selftests: pmtu: Factor out MTU parsing helper Stefano Brivio
2018-03-15 16:18 ` [PATCH net-next 3/9] selftests: pmtu: Introduce support for multiple tests Stefano Brivio
2018-03-16 18:06 ` David Ahern
2018-03-16 19:29 ` Stefano Brivio
2018-03-16 19:53 ` David Ahern
2018-03-16 20:03 ` Stefano Brivio [this message]
2018-03-15 16:18 ` [PATCH net-next 4/9] selftests: pmtu: Add pmtu_vti4_default_mtu test Stefano Brivio
2018-03-15 16:18 ` [PATCH net-next 5/9] selftests: pmtu: Add pmtu_vti6_default_mtu test Stefano Brivio
2018-03-15 16:18 ` [PATCH net-next 6/9] selftests: pmtu: Add pmtu_vti4_exception test Stefano Brivio
2018-03-15 16:18 ` [PATCH net-next 7/9] selftests: pmtu: Add pmtu_vti4_link_add_mtu test Stefano Brivio
2018-03-15 16:18 ` [PATCH net-next 8/9] selftests: pmtu: Add pmtu_vti6_link_add_mtu test Stefano Brivio
2018-03-15 16:18 ` [PATCH net-next 9/9] selftests: pmtu: Add pmtu_vti6_link_change_mtu test Stefano Brivio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180316210320.48a1b17e@epycfail \
--to=sbrivio@redhat.com \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sd@queasysnail.net \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.