astroquery.mast remote data unit tests breaking

[jaymedina]

When running pytest I found that a couple of the unit tests under test_mast_remote.py are breaking, I think mainly due to no products found with the given input(s). Here's the error message I get:

================================================================================================================= short test summary info ==================================================================================================================
FAILED test_mast_remote.py::TestMast::test_observations_get_product_list - assert 27 == 30
FAILED test_mast_remote.py::TestMast::test_observations_download_products - astroquery.exceptions.NoResultsWarning: Query returned no results.
FAILED test_mast_remote.py::TestMast::test_observations_download_file - astroquery.exceptions.NoResultsWarning: Query returned no results.
FAILED test_mast_remote.py::TestMast::test_catalogs_query_region - astroquery.exceptions.MaxResultsWarning: Maximum catalog results returned, may not include all sources within radius.
FAILED test_mast_remote.py::TestMast::test_catalogs_query_criteria - assert 316 >= 400
FAILED test_mast_remote.py::TestMast::test_tesscut_get_sectors - astroquery.exceptions.NoResultsWarning: Coordinates are not in any TESS sector.
FAILED test_mast_remote.py::TestMast::test_zcut_get_surveys - astroquery.exceptions.NoResultsWarning: Coordinates are not in an available deep field survey.
FAILED test_mast_remote.py::TestMast::test_zcut_download_cutouts - astroquery.exceptions.NoResultsWarning: No data at cutout size/location. Cutout not performed.
FAILED test_mast_remote.py::TestMast::test_zcut_get_cutouts - astroquery.exceptions.NoResultsWarning: No data at cutout size/location. Cutout not performed.
========================================================================================================= 9 failed, 30 passed in 186.62s (0:03:06) =========================================================================================================

[bsipocz]

Yes, these are the ones I saw, too. I think we should rethink whether it's the right approach to expect a precise number of results in the entry, etc. (Though it's a bit weird why the numbers are lower than they used to be, after all, all these tests used to pass and one would expect that more data gets into the archive and not less).

[jaymedina]

Agreed - I haven't looked into the context of these unit tests but I've made a config.py file for our internal unit tests that makes some of these queries "future-proof" - so independent of how the database changes (OBSIDs can change, and as you said the # of products can change). I can look into how to integrate this on the front end without disclosing internal information.