Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable configuring fixtures per test #6226

Open
4 tasks done
acidoxee opened this issue Jul 26, 2024 · 0 comments
Open
4 tasks done

Enable configuring fixtures per test #6226

acidoxee opened this issue Jul 26, 2024 · 0 comments
Labels
p2-nice-to-have Not breaking anything but nice to have (priority)

Comments

@acidoxee
Copy link

Clear and concise description of the problem

Currently, setup functions of fixtures execute the same way for each test. This is fine for most, but configuring the way the fixture is initialized per test/per test suite would be great for more complex cases.

For instance, consider the following setup with beforeEach/afterEach hooks for a given test suite:

describe('Context foo', () => {
  let db;

  beforeEach(async () => {
    db = await createTestDb({
      // This should be configurable per test suite, or sometimes even per test if using `createTestDb` directly
      schemaName: 'foo',
      // This as well
      pathLayer: 'foo',
      // And this as well
      seed: false,
    });
  });

  afterEach(async () => {
    await clearTestDb(db);
  });

  test('Test 1', async () => {
    // Some random ID
    db.name;
    // Client setup for this test
    db.client;
  });

  test('Test 2', async () => {
    // Another random ID
    db.name;
    // Different client instance
    db.client;
  });
});

describe('Context bar', () => {
  let db;

  beforeEach(async () => {
    db = await createTestDb({
      schemaName: 'bar',
      pathLayer: 'bar',
      seed: true,
    });
  });

  afterEach(async () => {
    await clearTestDb(db);
  });

  test('Test 3', async () => {
    // Yet another random ID
    db.name;
    // Client instance 3
    db.client;
  });
});

The setup is verbose, but flexible as it enables test-specific setups.

Suggested solution

It would be great to have an equivalent setup with fixtures, which could look like this:

// Default fixture setup for every test of the project. This is written only once in a setup file
test = test.extend({
  db: async ({ schemaName, pathLayer, seed }, use) => {
    const db = await createTestDb({ schemaName, pathLayer, seed });
    await use(db);
    await clearTestDb(db);
  },
  schemaName: 'public',
  pathLayer: 'public',
  seed: false,
});

// Specific test suite
describe('Context foo', () => {
  test.use({ schemaName: 'foo', pathLayer: 'foo', seed: false });

  test('1', async ({ db }) => {
    // Some random ID
    db.name;
    // Client setup for this test
    db.client;
  });

  test('2', async ({ db }) => {
    // Another random ID
    db.name;
    // Different client instance
    db.client;
  });
});

describe('Context bar', () => {
  test.use({ schemaName: 'bar', pathLayer: 'bar', seed: true });

  test('3', async ({ db }) => {
    // Yet another random ID
    db.name;
    // Client instance 3
    db.client;
  });
});

This is how Playwright enables configuring fixtures per test/per test suite (see here and there). They also have a concept of "option" fixtures, which might be suited for the aforementioned schemaName, pathLayer and seed fixtures (but they also have a concept of per-project config of those options, so I'm not sure whether this option concept should apply to Vitest in the same regard).

Alternative

No response

Additional context

Initially posted as a question on Discord.

Validations

@sheremet-va sheremet-va added p2-to-be-discussed Enhancement under consideration (priority) and removed enhancement: pending triage labels Jul 31, 2024
@sheremet-va sheremet-va moved this to P2 - 4 in Team Board Jul 31, 2024
@sheremet-va sheremet-va moved this from P2 - 4 to Approved in Team Board Aug 1, 2024
@sheremet-va sheremet-va added p2-nice-to-have Not breaking anything but nice to have (priority) and removed p2-to-be-discussed Enhancement under consideration (priority) labels Aug 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p2-nice-to-have Not breaking anything but nice to have (priority)
Projects
Status: Approved
Development

No branches or pull requests

2 participants