Differentiate between "tests" and "test infrastructure"
Categories
(Webtools :: Searchfox, enhancement)
Tracking
(Not tracked)
People
(Reporter: asuth, Unassigned)
Details
Using the example of flushPrefEnv, there are uses under testing/mochitest and testing/specialpowers that are significantly more interesting than the test-file uses.
All of the test infrastructure files are already properly mapped to "Testing :: Mochitest" by the relevant moz.build files.
A notable thing in terms of testing is that, for example, testing/web-platform/moz.build does a fantastic job of mapping tests to the platform bugzilla components they are tests for, which means that it's probably safe to map the m-c "Testing" product directly to test infrastructure without worrying that tests in general will be mis-categorized to test infrastructure. The exception is some trees like tests/annotation-* all get lumped into a catch-all "Testing" :: "web-platform-tests" still, which would need to be specialized to be correspond just to tests.
Tests of test infrastructure would likely be mis-categorized unless some additional heuristic looked for the presence of an additional "test" token under the root of the moz.build Files "**" glob. I don't think that's something that's currently directly available, but it would likely be a simple enough heuristic to put in m-c's repo_files.py for example as a limited targeted specialization. Which is also where the "Testing" :: "web-platform-tests" would get specialized too.
Potential feature creep would be optional faceting of tests by bugzilla product::component. Because there's frequently a secondary level of hierarchy embedded in the component string (ex: "Core" :: "DOM: Service Workers"), this could end up preferable to only supporting path-based faceting.
Description
•