1268535 - Move static-type general mochitest browser tests into their own directory and remove browser_parsable_script.js

Status: RESOLVED DUPLICATE of bug 1347947

(Firefox :: General, defect)

Description

[:Gijs (he/him)]

We now have eslint coverage, so we don't need parsable_script.js anymore.

The other tests, parsable_css.js and the string checks, should probably live in their own directory - they take a long time (making it look like the tests are hanging when running them locally) and are quite different from the other tests. At least parsable_script.js has intermittent failures; I wouldn't be surprised that if we make the css and/or string tests more elaborate, they will take longer and longer and suffer similar problems if run as part of browser/base/content/test/general. Hopefully moving them to their own directory will help with running them locally, and with intermittents on infra. It'll also make it easier to then (decide to) convert them to taskcluster-style linting checks like we have done for eslint. If we want to be more ambitious we can try doing that in this bug, I guess.

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

Are we sure that eslint covers all parsing checks that SpiderMonkey will? I would prefer to keep both.

Comment 2

[:Gijs (he/him)]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #1)
> Are we sure that eslint covers all parsing checks that SpiderMonkey will? I
> would prefer to keep both.

This makes some sense, at least until we have SpiderNode.

The problem with these tests is that we're effectively abusing the browser-mochitest framework. All of them could probably be converted to xpcshell tests so they run slightly more quickly, even if we don't go whole-hog and do them in python as taskcluster jobs (which seems like it ought to be feasible for the strings stuff, but I haven't really looked into that too much).

Comment 3

[Mark Banner (:standard8)]

Bug 1347947 moved the tests.

Regarding browser_parsable_script.js I don't think it hurts to have that running as long as it isn't too expensive on test run time.

ESLint runs on the majority of our processed scripts now, but we can't always get the configuration 100% correct, and even if we could there's third party imports and the small bit of preprocessed code that we don't run through it. Hence, I think it is worth keeping.

Going to mark this as a duplicate of bug 1347947 as that did most of the work here.