Skip to content

feat(runner): support automatic fixtures#5102

Merged
sheremet-va merged 7 commits intovitest-dev:mainfrom
fenghan34:feat/automatic-fixtures
Feb 16, 2024
Merged

feat(runner): support automatic fixtures#5102
sheremet-va merged 7 commits intovitest-dev:mainfrom
fenghan34:feat/automatic-fixtures

Conversation

@fenghan34
Copy link
Copy Markdown
Contributor

@fenghan34 fenghan34 commented Feb 2, 2024

Description

To close #4953, this PR adds the automatic fixtures feature, allowing users to explicitly initialize fixtures even they are not being used in tests.

Like Playwright, users can use the tuple syntax to pass options for each fixture through the second element. And Only if supported options (currently, only the auto option) are passed, we consider it as a fixture with options.

So below is an automatic fixture:

import { test as base } from 'vitest'

const test = base.extend({
  fixture: [
    async ({}, use) => {
     // this function will run automatically
      setup()
      await use()
      teardown()
    },
    { auto: true } // Mark as an automatic fixture
  ],
})

test('', () => {})

And here are normal fixtures:

import { test as base, expect } from 'vitest'

const test = base.extend({
  fixture1: [
    async ({}, use) => {
      // this function will not run automatically
      setup()
      await use()
      teardown()
    },
  ],
  fixture2: [
    async ({}, use) => {
      // this function will not run automatically
      setup()
      await use()
      teardown()
    },
   { foo: 1 }
  ],
})

test('', ({ fixture1, fixture2 }) => {
  expect(fixture1).toBeInstanceOf(Array)
  expect(fixture2).toBeInstanceOf(Array)
})

Not quite sure if it's the right solution for the tuple syntax, I'm following Playwright's behavior for compatibility, would love to receive some feedback, thanks!

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.

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:.

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Playwright-style automatic fixtures

3 participants