[IPython-dev] IPython.zmq tests
benjaminrk at gmail.com
Sat Jan 21 18:24:20 EST 2012
On Sat, Jan 21, 2012 at 15:12, Fernando Perez <fperez.net at gmail.com> wrote:
> On Sat, Jan 21, 2012 at 3:02 PM, Thomas Kluyver <takowl at gmail.com> wrote:
>> While playing with the test suite, I've just noticed that the standard
>> iptest command doesn't run the tests in IPython.zmq. I don't know if this
>> was deliberately disabled or simply overlooked, but running those tests
>> (iptest IPython.zmq) now is not pretty. ZMQ complains about contexts
>> terminating or not terminating, several terminal editors pop up and have to
>> be dismissed, and when it's finished, it hangs and has to be killed
>> manually. Since the other things are working, I guess it's more of an issue
>> with the tests than the code itself, but it could still do with some
> Ouch: it was most likely that when we got the machinery up and running
> we were struggling with some of those, disabled them temporarily and
> simply forgot to re-enable them. It was most certainly *not* intended
> to stay that way, and I'd say it's pretty high priority that we fix
> that now. It's perfectly possible that some of those failures are
> true bugs whose consequences we may be seeing elsewhere, so we should
> definitely try to get that fixed up.
No, they were never enabled because IPython.zmq has *never* had any
tests. The only tests there are for IPython.zmq.session, which only
exist because the Session object was originally in IPython.parallel,
which is tested. Almost all of the failures/errors are because there
are some entry points (like IPython.zmq.frontend) which start blocking
calls when imported, causing problems when included in the test
search. Further, since the test suite has never been run on
IPython.zmq, the necessary @skip_doctests haven't been applied all
over the place, so the silly doctest scraper will find all the
examples that won't actually run in an unconfigured environment.
The real issue is that we need tests for IPython.zmq.
> In order not to pollute master with a big batch of new failures, I
> suggest we do this in a branch. If you want to tackle it and it looks
> quick, do it like a regular PR. Otherwise we can make a shared branch
> on the main repo so that multiple people can pitch in as necessary.
> Thanks for finding this!
> IPython-dev mailing list
> IPython-dev at scipy.org
More information about the IPython-dev