You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When identifying tests, the WPT infrastructure ignores files whose name (not including extension) ends in -support. Today, only 13 files meet that criteria:
I'd like remove the infrastructure that recognizes the -support file name pattern and relocate the files that rely on it to an appropriately-named subdirectory. My motivation is to reduce the learning curve for contribution and limit the number of ways to express the same thing. In addition, four of the -support files listed above appear to actually be tests. If so, they are evidence that the naming scheme is prone to accidental opt-in.
Does anyone know of a reason why this simplification cannot or should not be made? @gsnedders or @jgraham, perhaps?
The text was updated successfully, but these errors were encountered:
I guess this is fine, though I don't think we particularly need to start moving these tests. I expect the actual support files will end up in the default case in SourceFile.manifest_items() and be treated as support files anyway.
When identifying tests, the WPT infrastructure ignores files whose name (not including extension) ends in
-support
. Today, only 13 files meet that criteria:$ git ls-files | grep '\-support\.'
The infrastructure also ignores files placed within subdirectories named "resources", "tools", or "support". That approach is far more common:
I'd like remove the infrastructure that recognizes the
-support
file name pattern and relocate the files that rely on it to an appropriately-named subdirectory. My motivation is to reduce the learning curve for contribution and limit the number of ways to express the same thing. In addition, four of the-support
files listed above appear to actually be tests. If so, they are evidence that the naming scheme is prone to accidental opt-in.Does anyone know of a reason why this simplification cannot or should not be made? @gsnedders or @jgraham, perhaps?
The text was updated successfully, but these errors were encountered: