Re: [RFCv3 09/15] selftests: tcp_authopt: Test key address binding

[Leonard Crestez]

On 25.08.2021 08:18, David Ahern wrote:
> On 8/24/21 2:34 PM, Leonard Crestez wrote:
> > By default TCP-AO keys apply to all possible peers but it's possible to
> > have different keys for different remote hosts.
> >
> > This patch adds initial tests for the behavior behind the
> > TCP_AUTHOPT_KEY_BIND_ADDR flag. Server rejection is tested via client
> > timeout so this can be slightly slow.
> >
> > Signed-off-by: Leonard Crestez <cdleonard@xxxxxxxxx>
> > ---
> >   .../tcp_authopt_test/netns_fixture.py         |  63 +++++++
> >   .../tcp_authopt/tcp_authopt_test/server.py    |  82 ++++++++++
> >   .../tcp_authopt/tcp_authopt_test/test_bind.py | 143 ++++++++++++++++
> >   .../tcp_authopt/tcp_authopt_test/utils.py     | 154 ++++++++++++++++++
> >   4 files changed, 442 insertions(+)
> >   create mode 100644 tools/testing/selftests/tcp_authopt/tcp_authopt_test/netns_fixture.py
> >   create mode 100644 tools/testing/selftests/tcp_authopt/tcp_authopt_test/server.py
> >   create mode 100644 tools/testing/selftests/tcp_authopt/tcp_authopt_test/test_bind.py
> >   create mode 100644 tools/testing/selftests/tcp_authopt/tcp_authopt_test/utils.py
>
> This should be under selftests/net as a single "tcp_authopt" directory
> from what I can tell.

Maybe? I found no clear guidelines for organizing tests by subsystem. I 
just did a grep for .py in selftests and placed mine next to tc-testing.

Having a tcp_authopt_test code directory under tcp_authopt is the 
standard pattern for python packages, otherwise all submodules with 
utilities of dubious generality are dumped at the global level. Removing 
the tcp_authopt/tcp_authopt_test structure is awkward in python.

One way to deal with this is to add my test code in 
tools/testing/selftests/net/tcp_authopt and my setup.cfg and similar 
directly in tools/testing/selftests/net. This would make "net" the root 
of the package and make it easy to add other networking pytests. This 
seems close to what you mean.

kselftest itself does not seem to offer any special support for python 
code, only some for C and shell. Maybe it could offer a "kselftest" 
package with common utilities that are used by multiple test packages 
and everything would be installed into a single virtualenv by makefiles.

--
Regards,
Leonard