Re: Re: Zope tests: 4 OK, 2 Failed
Tim Peters <[email protected]>
| Newsgroups | gmane.comp.web.zope.coders |
|---|---|
| Message-ID | <[email protected]> |
[Stefan H. Holek, on testRunIgnoresParentSignals]
> Right. The test only fails in the nightly runs. It passes fine when I
> run the tests from the command line. Let's see what I can do
> about that...
A good start would be to rewrite the test, so that it becomes possible
to guess something about the cause of failure when it does fail. For
example, the test's
try:
response = send_action('status\n', zdrun_socket) or ''
except socket.error, msg:
response = ''
is silly, because send_action() suppresses socket.error. IOW, the
try/except block here is useless. Better would be, e.g.,
response = (send_action('status\n', zdrun_socket) or
"send_action failed")
Better still may be to change send_action() to record why it fails
when it fails.
Then the actual raising of a failure loses all useful information:
self.assert_(len(params) > 1)
That doesn't tell you whether the response was empty, or not empty but
not of the expected form, or what. Better here would be, e.g.,
if '\n' not in response:
self.fail("expected at least one newline in response %r" %
response)
*If* it's failing because spawnvp doesn't have time to get the new
processes running, what actually happens in this test is that its
first send_action() call suppresses a socket.error with a detail of
the form
(2, 'No such file or directory')
The test turns send_action's None return in that case into an empty
string, and then splitting an empty string by '\n' yields the list
['']
and so
self.assert_(len(params) > 1)
triggers. I'm guessing that is what's happening, too, but it's
impossible to be sure of that now from the test's useless failure
output.