Split Tests/UnitTests/Scripts/tests.ts into per-polyfill spec files
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 58/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- typescript
- Domain
- testing
Research direction
Start by reading Tests/UnitTests/Scripts/tests.ts and tracing how the test harness loads it. Identify the shared server bootstrap and fixtures, then separate the existing describe blocks into per-polyfill spec files under Scripts/tests with a small barrel or entrypoint. Done means the harness still loads every spec and the full unit test suite passes.
Written by the indexing model from the issue text.
Description
Summary
Tests/UnitTests/Scripts/tests.ts has grown to ~1.5k lines spanning 15+ describe blocks across 10+ polyfills (XHR, WebSocket, Blob, File, FileReader, TextEncoder/Decoder, URL, Console, Scheduling, AbortController, napi prototype isolation, ...). Every new polyfill grows this single file further, which hurts readability, makes ownership/blame noisy, and increases merge-conflict surface.
Proposal
Split the suite into one spec file per polyfill (e.g. Scripts/tests/xhr.ts, blob.ts, file.ts, filereader.ts, ...) with a small barrel/entrypoint that the test harness loads. Keep shared helpers (server bootstrap, fixtures) in a common module.
Context
Raised in review of #169 (File / FileReader polyfill). Filing as a standalone follow-up so that PR's diff stays focused on the polyfill itself rather than a large test reorganization.
- Dominant language
- C++
- Stars
- 22
- Forks
- 23
- Avg merge
- 4d 8h
- Merged PRs (30d)
- 3
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from BabylonJS/JsRuntimeHost
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
BabylonJS/JsRuntimeHost#234 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
BabylonJS/JsRuntimeHost#173 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
BabylonJS/JsRuntimeHost#241 · 3 comments ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
BabylonJS/JsRuntimeHost#228 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 68/100
BabylonJS/JsRuntimeHost#226 ·
Maintainers usually reply within 1 day
All issues in BabylonJS/JsRuntimeHost
Similar issues
-
bug chart-audit
Difficulty 1/5 Under an hour Newbie friendliness 92/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
godotengine/godot#124120 ·
Maintainers usually reply within 1 day
-
Component: R Type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
apache/arrow#51695 · 1 comment ·
Maintainers usually reply within 1 day
-
HasBacktrace Priority-Critical
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
azerothcore/azerothcore-wotlk#27921 ·
Maintainers usually reply within 1 day
-
area/ysql kind/bug priority/medium
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
yugabyte/yugabyte-db#34584 ·
Maintainers usually reply within 1 day