W3C home > Mailing lists > Public > public-test-infra@w3.org > July to September 2016

Re: Tests that fail due to server problems

From: Geoffrey Sneddon <me@gsnedders.com>
Date: Wed, 14 Sep 2016 00:12:25 +0100
Message-ID: <CAHKdfMjebkJMMgK=AVWOPOUH0LrYp3=8eYXsTzPmAAW1-XikCA@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: public-test-infra <public-test-infra@w3.org>
On Tue, Sep 13, 2016 at 11:53 PM, Mark Watson <watsonm@netflix.com> wrote:
> We have some tests (for encrypted-media) which rely on a 3rd party server.
> Presently, if that server fails then the tests report TIMEOUT, which is then
> indistinguishable (for some of the tests) from certain kinds of test failure
> (for example, video was expected to start but never did).
> What is the appropriate result when the inability to complete the test is
> due to such a 3rd party dependency, rather than a problem with the
> implementation under test ? Should this be NOTRUN ? How do we trigger this ?

Is there any way to avoid the 3rd party dependency? Typically browser
vendors have attempted to avoid 3rd party dependencies in tests at all
costs given it leads to a substantial increase in intermittent
failures, and tests that fail intermittently typically get disabled,
especially when they cannot be fixed. (You can't gate landing a patch
on tests passing if they fail intermittently 0.01% of the time, as
with a large number of tests it becomes a significant percentage of
test runs that end up with some intermittent failure, hence you end up
unable to land any patch.)

As a result, practically the tests are going to end up being manual
tests regardless of automation or not. As such, I'd suggest what the
actual status returned is is relatively irrelevant.

I presume from your question that there's some way to detect when the
3rd party server fails to respond—I guess what I'd suggest is having
the tests fail if the server fails to respond, with a description
saying as much (and probably saying to try running it again).

Received on Tuesday, 13 September 2016 23:12:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:34:12 UTC