feat: Add configurable test identifiers for static parsing

[jgillick]

Description

seeking feedback

This configures the test function names used by the AST parser.

When creating custom test context functions (for example:testDb and testNetwork), these are not discovered by tools like the vitest vscode extension. This means that the extension does not provide the on-off test icon in the gutter next to the test.

This stage of the PR is incomplete and seeking feedback on the approach before moving further into writing unit tests, documentation, and/or adding the other strings to the configuration.

Resolves vitest-dev/vscode#649

Why

In my code base, we've created several custom test contexts:

• testDb - Provides the DB connector and adds setup/teardown for that test.
• testNetwork - Provides a reference to msw and performs setup/teardown for the test.

Unfortunately, these are not recognized by the vitest vscode extension, so we don't get the option to run the test as a one-off without running the entire suite. We also don't want to make these the default tests because it can be heavy to setup/teardown a DB for tests that do not need it.

Usage

In this example, the end user would just, optionally, add a new ast section to their vitest configuration:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  ast: {
    test: ['it', 'test', 'testDb', 'testNetwork']
  },
  // ...other config items...
});

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
• Ideally, include a test that fails without this PR but passes with it.
• Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.
• Please check Allow edits by maintainers to make review process faster. Note that this option is not available for repositories that are owned by Github organizations.

Tests

• Run the tests with pnpm test:ci.

Documentation

• If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

• Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

[netlify]

✅ Deploy Preview for vitest-dev ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	c01ebd7
🔍 Latest deploy log	https://app.netlify.com/projects/vitest-dev/deploys/6949bf32ffc43900080dff04
😎 Deploy Preview	https://deploy-preview-9235--vitest-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[sheremet-va]

This seems like a bad developer experience. I wonder if we should instead define a convention for these names and respect it when parsing.

[jgillick]

That's another possibility. Honestly, when I ran into this problem, I was hoping that I could just name the function ____Test or test____ (dbTest / testDb) and it would automatically get recognized. Is this a good naming convention? Could it create bad false positives?

[sheremet-va]

That's another possibility. Honestly, when I ran into this problem, I was hoping that I could just name the function ____Test or test____ (dbTest / testDb) and it would automatically get recognized. Is this a good naming convention? Could it create bad false positives?

I think it's good enough. We just ignore all the functions that don't follow test(name, fn) or test(name, options, fn), so it should be fine. We also only parse test files themselves.

[jgillick]

@sheremet-va thank you for your feedback. I've updated the PR to instead look for functions name ending in "Test". The current check is pretty basic, but it could be updated to a regex expression, if we want.

I haven't fully tested this yet, and wanted to first get a temperature check before continuing.

[sheremet-va]

I've updated the PR to instead look for functions name ending in "Test".

I don't think this fixes your use cases:

In my code base, we've created several custom test contexts:
testDb - Provides the DB connector and adds setup/teardown for that test.
testNetwork - Provides a reference to msw and performs setup/teardown for the test.

Both of them start with test. I think we can support both startsWith and endsWith

[jgillick]

I don't think this fixes your use cases:

Indeed. I was just planning to change my functions to match this convention, but I can also update the PR to do both.