[1.2RC1]: Test failures in test_conesearch and coordinates docstrings

[mirca]

• OSX El Capitan 10.11.5
• Python 3.5.1

======================================== FAILURES ========================================
_______________________________ TestConeSearch.test_async ________________________________

self = <astropy.vo.client.tests.test_conesearch.TestConeSearch object at 0x10cb77780>

    def test_async(self):
        async_search = conesearch.AsyncConeSearch(
            SCS_CENTER, SCS_RADIUS, pedantic=self.pedantic)

        tab = async_search.get(timeout=data.conf.remote_timeout)

>       assert async_search.done()
E       assert <bound method Future.done of <Future at 0x10cb77550 state=running>>()
E        +  where <bound method Future.done of <Future at 0x10cb77550 state=running>> = <astropy.vo.client.conesearch.AsyncConeSearch object at 0x10cb775f8>.done

astropy/vo/client/tests/test_conesearch.py:154: AssertionError
_____________________________ TestConeSearch.test_async_all ______________________________

self = <astropy.vo.client.tests.test_conesearch.TestConeSearch object at 0x10cb7f3c8>

    def test_async_all(self):
        async_search_all = conesearch.AsyncSearchAll(
            SCS_CENTER, SCS_RADIUS, pedantic=self.pedantic)

        all_results = async_search_all.get(timeout=(data.conf.remote_timeout * 3))

>       assert async_search_all.done()
E       assert <bound method Future.done of <Future at 0x10cc41c50 state=running>>()
E        +  where <bound method Future.done of <Future at 0x10cc41c50 state=running>> = <astropy.vo.client.conesearch.AsyncSearchAll object at 0x10cc413c8>.done

astropy/vo/client/tests/test_conesearch.py:163: AssertionError
__________________________ [doctest] docs/coordinates/index.rst __________________________
195     >>> c1.separation(c2)  # Differing frames handled correctly  # doctest: +FLOAT_CMP
196     <Angle 1.4045335865905868 deg>
197 
198 The `astropy.coordinates` subpackage also provides a quick way to get
199 coordinates for named objects assuming you have an active internet
200 connection. The `~astropy.coordinates.SkyCoord.from_name` method of |skycoord|
201 uses `Sesame <http://cds.u-strasbg.fr/cgi-bin/Sesame>`_ to retrieve coordinates
202 for a particular named object::
203 
204     >>> SkyCoord.from_name("M42")  # doctest: +REMOTE_DATA +FLOAT_CMP
Expected:
    <SkyCoord (ICRS): (ra, dec) in deg
        (83.82208, -5.39111)>
Got:
    <SkyCoord (ICRS): (ra, dec) in deg
        (83.8186621, -5.3896789)>

/private/tmp/astropy-test-x6ing2jr/docs/coordinates/index.rst:204: DocTestFailure
_____________________ [doctest] docs/coordinates/remote_methods.rst ______________________
006 ---------------------------------------------------------------
007 
008 There are currently two methods that rely on getting remote data to work.
009 
010 The first is the :class:`~astropy.coordinates.SkyCoord` :meth:`~astropy.coordinates.SkyCoord.from_name` method, which uses
011 `Sesame <http://cds.u-strasbg.fr/cgi-bin/Sesame>`_ to retrieve coordinates
012 for a particular named object::
013 
014     >>> from astropy.coordinates import SkyCoord
015     >>> SkyCoord.from_name("M42")  # doctest: +REMOTE_DATA +FLOAT_CMP
Expected:
    <SkyCoord (ICRS): (ra, dec) in deg
        (83.82208, -5.39111)>
Got:
    <SkyCoord (ICRS): (ra, dec) in deg
        (83.8186621, -5.3896789)>

/private/tmp/astropy-test-x6ing2jr/docs/coordinates/remote_methods.rst:15: DocTestFailure
============ 4 failed, 8429 passed, 130 skipped, 37 xfailed in 757.01 seconds ============

[eteq]

Hmm, the second two (the coordinates doctests) look to be due to the name resolver getting the NED coordinates instead of the Simbad. I think I noticed some problems with Simbad earlier today, so @mirca, can you try again and see if it goes away?

The first two look like they might be due to some query taking too long? I'm guessing that based on it saying "running" when it's supposed to be done. At any rate, I don't see it when I run it myself locally, so I think it's a site-specific issue rather than a problem with the code? @pllim can probably shed some light on the conesearch ones, though.

[pllim]

The Cone Search failures were briefly discussed at the end of #4896. Looking at the service validation results from last night, I bet you won't see those anymore if you rerun your tests. But if you do, there is nothing much I can do except to mark them as xfail if assertion fails, as @eteq suggested in the other thread.

[mirca]

I think this can be closed, right? @pllim

[pllim]

The conesearch failure appears to be real but potential fix in #5366