ENH: Add ability to run a resource's test-query

[delucchi-cmu]

Most registry entries have some form of test_query, that is used for validation.

It would be nice to have this exposed to pyvo users for an on-demand resource validation.

In addition to finding out if this passes or fails, it would be great to also indicate how long the test took, so multiple resources could be compared to find the most suitable resource for your network or geo-location.

[delucchi-cmu]

Discussed with @bsipocz

[bsipocz]

For more context: we were looking into things that could be done in pyvo to support HATs, and while most of the methods existing in the registry doesn't apply, a quick "validation" that the resource exists and works may be useful. And for this we were thinking of reusing the test query that is being added to the registry entry.

I think this maybe useful for other servicetypes, too.

[msdemlei]

On Thu, Jun 11, 2026 at 06:19:03AM -0700, Brigitta Sipőcz wrote: bsipocz left a comment (astropy/pyvo#766) registry doesn't apply, a quick "validation" that the resource exists and works may be useful. And for this we were thinking of reusing the test query that is being added to the registry entry.

Hm. When would you use such a thing in a normal science client? I will freely admit that my creed has always been the Python pragmatics: Just jump and see, but be prepared to fall (rather than ask permission first). In that sense, I'd almost always argue for making a client just run whatever it is trying to do and then fail with as expressive an error message as possible rather than try to sense up front whether anything might go wrong. It may be that HATS has special requirements, but these would need to be spelled out as clearly as possible so that we can see what the least intrusive method to satisfy them might be. With these preliminaries: This isn't very simple to do because none of the testQuery-related RegTAP details are mandatory (see RegTAP Appendix A), and so we can't reliably pull them from where we pull all the other stuff. That means that to figure out the test query, a client would have to retrieve and parse the VOResource record, either from a full harvesting registry or perhaps even from the originating publishing registry. The global validators do something like this, and so could pyVO. But it does nothing like that elsewhere at the moment, and so let's have a very clear idea of why we as a non-validating client ("be lenient in what you accept") should be doing that.