[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-inetutils] Re: [PATCH] Inetd and test scripts
From: |
Alfred M. Szmidt |
Subject: |
Re: [bug-inetutils] Re: [PATCH] Inetd and test scripts |
Date: |
Fri, 05 Nov 2010 12:45:28 -0400 |
> Now, ???netstat??? isn???t provided by Inetutils, so it???ll have to be
> ???AC_PATH_PROG???d, and the test will have to be skipped if it isn???t
> found.
In my view a test program is not part of a software distribution.
It is there to provide a tool, and a also a demonstration in what
ways a piece of software has been tested, for the verification
that the intended services behave as they were conceived.
I have to disagre to a point, any user who can install inetutils
should be able to run the testsuite. If a specific program is needed,
then we should fail gracefully.
You are right about skipping. Write a patch suggestion! The trivial
one needs more context:
test -x netstat || exit 1
Can we get the info from netstat in another way, maybe implementing
netstat ourselfs?
The very first issue of "tftp.sh" failed completely
for OpenBSD. I had fixed that and submitted, only to find that this
fix failed for FreeBSD and GNU/kFreeBSD once I booted such systems,
so I had to proceed to mend that also.
The testsuite in IU is still very very basic, we will have problems
with it while we build it up. It is very useful that we have NixOS
building, and running the tests due to its unorthodox configuration.
But even if it fails on NixOS, or anything else while we improve the
test suite that is fine; you cannot know if something breaks if you do
not know _if_ it breaks! Thus, both Ludovics and Mats efforts are
indispensible in improving the test suite or any other part of IU.
> For ???tftp.sh???, it doesn???t matter which one is failing. It???s a
tftp{,d}
> test. If something fails on the way, what matters is that the test
> actually fails.
I maintain my view point: It must at every time be possible to tell
exactly why a test fail. Was it due to the object under test, or was
it due to failer of the used tools?
I agree fully; what we can do is to seperate the common parts from the
tftp tests. But it is the only test of any daemon/client
configuration we have currently, and things will have to grow from
that.
> However, I agree that ???inetd??? alone should be tested as well.
There???s
> should be a different test for that, ideally a lower-level one, possibly
> treating ???inetd??? as a white box.
I agree again. Inetd must _also_ have its own test, but as long as
the tests are written as individual entities, it misses the target
to assume the correctness of each product of Inetutils that is being
used as a tool in a test. On the other hand, any tool from the running
OS should be assumed correct, but the test machinery must in an iterative
process be used in as many possible environments that differing output
from differing implementations be taken care of.
Agreed,
> -$INETD "${VERBOSE:+-d}" "$INETD_CONF" &
> +$INETD -d "$INETD_CONF" &
I expected and I was hoping to get this question!
This is tricky. Without "-d" the backgrounding fails, and the use of
the process number "$!" fails. Without "-d" Inetd will go into the
background itself, and the shell dash/bash/ksh/csh/tcsh will in "$!"
report the process number of the process that the shell in question
used to spawn the process, not the intended process number of "inetd".
Remember my harsh talk about robustness?
Can we fix this? I haven't looked at the code for inetd, but I'd say it is a
bug.
I would very much welcome alterations to eliminate those irritating
messages in [inetd] non-verbose mode, but I find myself having more urgent
business to attend to.
Me too! The test suite should spit all extra information into
seperate log files.
Re: [bug-inetutils] Re: [PATCH] Inetd and test scripts, Alfred M. Szmidt, 2010/11/02
Re: [bug-inetutils] Re: [PATCH] Inetd and test scripts, Alfred M. Szmidt, 2010/11/05