Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove some useless test-level properties #14519

Conversation

qiuzhong
Copy link
Contributor

Remove useless test-level properties, including:

  • Incorrect type of the properties parameter for promise_test()
  • flags property passed to test(), which is unused in testharness.js
  • Incorrect type of the properties generate_tests: moved to comments
  • help property: moved the head of the test files
  • Default empty properties dictionary
    Related: Remove testharness.js test-level asserts #14394

Remove useless test-level properties, including:
* Incorrect type of the properties parameter for `promise_test()`
* `flags` property passed to `test()`, which is unused in testharness.js
* Incorrect type of the properties `generate_tests`: moved to comments
* `help` property: moved the head of the test files
* Default empty properties dictionary
Related: web-platform-tests#14394
@@ -1,6 +1,34 @@
// NOTE: this file needs to be split up rather than expanded. See ../location.sub.html for some
// extracted tests. Tracked by https://github.com/web-platform-tests/wpt/issues/4934.

/*
* help:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cvrebert @zcorpan have you been using the test-level help metadata for these tests in any way? Ideas about how it could be used? I'm not sure if it's worth preserving or not as machine-readable metadata.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've written tests with help but it's likely less useful than a js line comment with a spec link (the only use I imagine is for someone debugging a test).

@@ -6,6 +6,13 @@
<link rel="author" title="Fabrice Clari" href="mailto:[email protected]">
<link rel="author" title="Dimitri Bocquet" href="mailto:[email protected]">
<link rel="help" href="https://html.spec.whatwg.org/multipage/#the-input-element">
<link rel="help" href="https://html.spec.whatwg.org/multipage/#dom-input-type">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ms2ger you added/edited the spec links in this test. Do you think we should keep them?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No opinion

@@ -330,16 +330,15 @@
};

window['MediaSourceUtil'] = MediaSourceUtil;
window['media_test'] = function(testFunction, description, options)
window['media_test'] = function(testFunction, description)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@qiuzhong can you separate out just this change? This is one that we definitely should do, since the options aren't used anywhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reverted the media_test function.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean that these are changes that we should land whether or not we remove properties entirely, so submitting those as a separate PR would be great.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I misunderstood your meaning. This time I reverted the whole test file and I'll file a new PR for it.

It's better to submit a new PR for this file.
@foolip
Copy link
Member

foolip commented Dec 20, 2018

This PR is blocked on the required "Travis CI - Pull Request" check after #14499. In order to trigger it, I will close and reopen this PR.

@foolip foolip closed this Dec 20, 2018
@dbaron
Copy link
Member

dbaron commented Mar 25, 2019

Behind the CSS test changes here is, I think, a question for @fantasai or @plinss: does the CSS WG intend to do something with per-test data for testharness.js-based tests of whether the test is testing invalid syntax?

@fantasai
Copy link
Contributor

@dbaron AFAIK, no. I think the main purpose of flagging 'invalid' was to let people use validator tools to help check syntax on their tests; flagging tests with deliberately invalid syntax would let the tools skip those tests. I don't think this logic applies to testharness.js tests, and I'm not aware of any other purpose for this metadata. Maybe @plinss knows more, though.

@plinss
Copy link
Contributor

plinss commented Mar 25, 2019

There were plans to use the per-test metadata in testharness.js tests a long time ago, but those have never developed and are unlikely to at this point.

Copy link
Member

@zcorpan zcorpan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can tell, this looks good. The PR needs to be rebased, though.

@dbaron
Copy link
Member

dbaron commented Aug 28, 2020

This can't currently be merged because the wpt-firefox-nightly-stability test is showing unstable results (timing out about 1/3 of the time) on various /html/infrastructure/urls/resolving-urls/query-encoding-* tests.

That seems likely to be an existing problem... I think?

@zcorpan
Copy link
Member

zcorpan commented Aug 28, 2020

See
https://bugs.chromium.org/p/chromium/issues/detail?id=930297
https://bugzilla.mozilla.org/show_bug.cgi?id=1034063
#4934

Yes, these tests are known unstable.

I can admin merge this. Thanks @dbaron !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants