X

Solaris serviceability and nifty tools

External contributions to testing community

I have just integrated couple of changes which I believe are the first contributed externally
to the Testing community as an open-source
contribution. The changes add couple of new tests to the
nc test suite to cover
the enhancement described in PSARC/2008/680
(which is present in Nevada since build 106).
This is the stuff which allows you to run nc(1) in client mode with complex portlist specifications. Previously
it was possible only to use simple port ranges like 22-80, with this change one can connect
to e.g. 22,24,50-80,66,1024-2048. Little example how it might be useful:

$ nc -v -z grok.czech 22,25,80-88,8080
Connection to grok.czech 22 port [tcp/ssh] succeeded!
nc: connect to 129.157.71.49 port 25 [host grok.czech] (tcp) failed: Connection refused
Connection to grok.czech 80 port [tcp/\*] succeeded!
nc: connect to 129.157.71.49 port 81 [host grok.czech] (tcp) failed: Connection refused
nc: connect to 129.157.71.49 port 82 [host grok.czech] (tcp) failed: Connection refused
nc: connect to 129.157.71.49 port 83 [host grok.czech] (tcp) failed: Connection refused
nc: connect to 129.157.71.49 port 84 [host grok.czech] (tcp) failed: Connection refused
nc: connect to 129.157.71.49 port 85 [host grok.czech] (tcp) failed: Connection refused
nc: connect to 129.157.71.49 port 86 [host grok.czech] (tcp) failed: Connection refused
nc: connect to 129.157.71.49 port 87 [host grok.czech] (tcp) failed: Connection refused
nc: connect to 129.157.71.49 port 88 [host grok.czech] (tcp) failed: Connection refused
Connection to grok.czech 8080 port [tcp/\*] succeeded!

Back to the testing part. The putback (yes, stcnv-gate is still using Teamware) log for this
change looks like this (I have modified Erik's e-mail a bit):

6786859 portranges_complex_spec is missing the listener
6754842 extended port list specification needs to be tested
Code contributed by Erik Trauschke <erik.trauschke AT freenet.de>

I think this is really nice example of the ideal state - the contributor not only did the feature part but
also the testing part. It shows a great degree of responsibility - not just throwing some code "over the fence"
but fully participating in the process to ensure the quality even in the long term.

The tests are both positive and negative. Each purpose in
portranges
directory is numbered and the following numbers match the test purpose numbers:

  • 5-12 ensure nc treats ports 0 and 65536 as invalid

    Previously, it was possible to listen on ports 0 and 65536, with Erik's changes this is no longer true
    so we need to add regression tests for both cases (client/server) and both ports.
  • 13-19 see if various malformed port list specifications are considered as invalid

    Each purpose needs not only positive tests which make sure the functionality actually works
    but also negative tests which ensure it does not misbehave. In this case, invalid port list
    specifications are thrown at nc(1) to see it reacts accordingly (with error, that is).
  • 20-25 test the functionality of complex port lists

    This is the bunch of test which see if the functionality actually works.
  • 26 tests reallocation

    Since the internal representation of the port list is now dynamically allocated and there is
    a default pre-allocated value which is reallocated if needed we need to test the case of reallocation.

To be able to do such integration there is now a
Test development process.
It's similar to the process used in ON community
but it's more lightweight. The main difference is that the request-sponsor part is done informally
via the testing-discuss mailing list and there is no list of bugs to pick up from. But don't
be shy, whether you're adding new functionality or completely new program, the
Testing community is here to help you.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.