Mark Update module tests skipped if run with the built-in PHP server

Thanks for opening this, Ted.

I asked in #bugsmash in Slack about this, since it seems more like a task to me.. There was general agreement that this isn't a bug:

What's the point in skipping tests here? I'm guessing the idea is that you run a whole test suite at once, but if some tests are skipped do you just say "eh, good enough"? I guess if it just fails it might not be as obvious as to why it failed and you might waste time debugging the failure.

- @mstrelan

It does seem like a task to me.

We could add an explanation in the docs somewhere, https://www.drupal.org/docs/develop/automated-testing →

- @quietone

Moving Category to task.

But sure, if we can't get the tests to tell us anything meaningful with the built-in PHP webserver, no objection to marking them skipped (assuming @mstrelan's point is in the right direction: better to skip than to fail in potentially confusing ways).

@dww thanks for the feedback.

I am open to not skipping the tests but if we don't I think we should check to see if the built-in in server is being used at the beginning and just fail the test with a good message about why. Currently the tests will fail but it is not clear why because there is not a good message. The request for the XML just doesn't return so difficult to understand why the test failed.

I do wonder if the scope of this issue needs to be broadened. Are update module tests the only ones that make requests that fail in this way? Seems a little hard to believe. 😅

Instead of manually doing weirdness in update module tests for this, can we come up with a more general solution?

I had the same thought as #4 and to be honest I haven't looked at the test(s) in question. I wondered if there is an attribute or annotation we can put on these tests, or a trait that they all use, or anything like that.