Add high-quality SKILL for compiler and fourslash tests#2929
Add high-quality SKILL for compiler and fourslash tests#2929
Conversation
…d fourslash tests Co-authored-by: RyanCavanaugh <6685088+RyanCavanaugh@users.noreply.github.com>
RyanCavanaugh
left a comment
There was a problem hiding this comment.
@copilot follow the proper skill format; this lacks the correct heder
…cture Co-authored-by: RyanCavanaugh <6685088+RyanCavanaugh@users.noreply.github.com>
| - Should not be manually edited (they'll be overwritten on regeneration) | ||
| - Provide coverage for ported TypeScript behavior | ||
|
|
||
| Hand-written tests (directly in `internal/fourslash/tests/` or in `manual/`): |
There was a problem hiding this comment.
Not sure if this matters because we have it elsewhere in repo instructions, but the tests in manual should correspond to a manually-fixed but generated test, so that's not exactly the right place for custom regression tests.
| 2. Check baseline diffs: `diff testdata/baselines/reference/compiler/failingTest.errors.txt testdata/baselines/local/compiler/failingTest.errors.txt` | ||
| 3. If the new output is correct, accept: `npx hereby baseline-accept` | ||
| 4. If not, fix the code and re-run | ||
|
|
There was a problem hiding this comment.
One thing I sometimes need to do when there's an unrecovered panic is to run all tests in a package sequentially (-parallel=1) and in verbose mode, such that the last test that shows up as running before the panic is the one that caused it. May or may not be worth adding it here, I only needed it a few times.
|
|
||
| #### Generating test variations | ||
|
|
||
| Options that affect program behavior (those marked with `AffectsProgramStructure`, `AffectsEmit`, `AffectsModuleResolution`, `AffectsDiagnostics`, etc.) can specify multiple values to generate separate sub-test configurations: |
There was a problem hiding this comment.
Basically any option can do variation, so this detail is not helpful.
|
|
||
| ```typescript | ||
| // @module: * | ||
| // @target: *, !es3 |
There was a problem hiding this comment.
This should use a better example than !es3 given I had to special case that to ignore it. We don't actually use this feature except for the one !es3 case, so it's probably not worth it anyway.
|
|
||
| #### Symlink tests | ||
|
|
||
| Use `// @link:` to create symlinks in the virtual filesystem: |
There was a problem hiding this comment.
I think this is wrong and only works for dir links due to some windows emulation constraints... which we don't have, so I personally just use @symlink.
|
|
||
| - `// @currentDirectory: /custom/path` — Set the working directory | ||
| - `// @noImplicitReferences` — Don't auto-include referenced files | ||
| - `// @lib: es2020,dom` — Specify lib files |
There was a problem hiding this comment.
This should note that lib is not variant, so commas just add more things.
| npx hereby test --tests "myNewTest" # Run tests matching a pattern (passed as -run flag) | ||
| ``` | ||
|
|
||
| #### Via Go directly (faster for specific tests) |
There was a problem hiding this comment.
We should only suggest go test for running single tests in verbose mode for print debugging. I don't think it's a great idea to use it otherwise, except for non-compiler tests.
| | `npx hereby test --race` | Enable Go race detector | | ||
| | `npx hereby test --coverage` | Generate coverage profiles | | ||
| | `npx hereby baseline-accept` | Accept local baselines as new reference | | ||
| | `npx hereby diff` | Diff baselines with tool from `$DIFF` env var | |
| ### 3.2 Environment Variables | ||
|
|
||
| | Variable | Purpose | | ||
| |----------|---------| | ||
| | `TSGO_BASELINE_TRACKING_DIR` | Directory for baseline usage tracking files | | ||
| | `TS_TEST_PROGRAM_SINGLE_THREADED` | Set to `false` for parallel test programs | | ||
| | `DIFF` | Path to diff tool for `npx hereby diff` | | ||
| | `TSGO_HEREBY_RACE` | Enable race detector via env var | | ||
| | `TSGO_HEREBY_NOEMBED` | Skip embedding bundled assets | |
There was a problem hiding this comment.
None of these should ever be set manually.
|
|
||
| #### Adding a new compiler test | ||
| 1. Create `testdata/tests/cases/compiler/myTest.ts` with test code and directives | ||
| 2. Run: `go test ./internal/testrunner/ -run 'TestLocal/compiler/myTest.ts'` |
There was a problem hiding this comment.
Should be hereby test, as that clears out the reference directory on startup. Often the agent will add a test, then accept baselines from other previous runs.
|
|
||
| #### Adding a new fourslash test | ||
| 1. Create `internal/fourslash/tests/myTest_test.go` with the test function | ||
| 2. Run: `go test ./internal/fourslash/tests/... -run TestMyTest` |
There was a problem hiding this comment.
I think this should too just do hereby test. It's really not that slow....
| ### 3.4 Key Source Files | ||
|
|
||
| | File | Purpose | | ||
| |------|---------| | ||
| | `internal/testrunner/compiler_runner.go` | Compiler test runner | | ||
| | `internal/testrunner/compiler_runner_test.go` | `TestLocal` and `TestSubmodule` entry points | | ||
| | `internal/testrunner/test_case_parser.go` | Parses `// @` directives from test files | | ||
| | `internal/fourslash/fourslash.go` | Fourslash test harness (all `Verify*` methods) | | ||
| | `internal/fourslash/test_parser.go` | Parses markers (`/*name*/`, `[|range|]`) | | ||
| | `internal/fourslash/baselineutil.go` | Fourslash baseline file generation | | ||
| | `internal/fourslash/tests/util/` | Shared test constants (`DefaultCommitCharacters`, etc.) | | ||
| | `internal/testutil/baseline/baseline.go` | Core baseline comparison and tracking | | ||
| | `Herebyfile.mjs` | Build/test task definitions | |
There was a problem hiding this comment.
I feel like this is pointless; maybe useful for generating this file, but if an agent reads these in the process of doing anything, it's just wasting context.
|
@copilot integrate everyone's feedback and push a new commit |
Co-authored-by: RyanCavanaugh <6685088+RyanCavanaugh@users.noreply.github.com>
Done in 45bec89. All feedback integrated:
|
Co-authored-by: RyanCavanaugh <6685088+RyanCavanaugh@users.noreply.github.com>
|
|
||
| #### Via hereby (recommended) | ||
|
|
||
| Always use `hereby test` for running tests. It ensures a clean state by clearing stale baselines before running, so results are always trustworthy. Trust the results — if `hereby test` passes, the tests pass. |
There was a problem hiding this comment.
Unfortunately I think this is the opposite of what @andrewbranch tries to use. It's not clear to me whether or not this matters, though, if this skill will be pulled in when doing other testing?
There was a problem hiding this comment.
I guess it talks more specifically below.
SKILL.mdinside a named directory with YAML frontmatter header💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.