Add a documentation page for how to use faker with testing frameworks

[Shinigami92]

We would like to have a documentation page that contains examples how to use faker in combination with testing frameworks like vitest and Cypress

[ST-DDT]

Maybe in a subsection of the Usage-Page.

[Shinigami92]

I would vote against creating a 100km scrollable usage page
It's a much better UX (especially on mobile screen) to have separate categories
I'm somewhat used to other VitePress docs like vuejs.org and vueuse.org
I usually search something quickly when sitting in the bus or other places where to use a mobile phone
On mobile you then also benefit from section switches at the bottom of the page, and you have a HARD time when scrolling to huge pages just to find the correct place, because you don't have the right context menu (yet) on mobile

[Shinigami92]

One of the best UX I had while searching and learning through docs on a mobile screen while being in a bug was: https://smallrye.io/smallrye-mutiny
I LOVE these arrows:

[ST-DDT]

I rarely try to debug an error/develop software while on the phone.
That's what large/multiple screens are for.
If I have a small screen then the search function is also very useful, if there is content that you can search in.
Especially the usage section, I look for code that looks like it might match and start reading. If I have to scroll both vertically and "horizontally" then I might miss the important piece because the headline was misleading.

[ST-DDT]

This should also include some "strange" caveeats of some of the test frameworks:
https://discord.com/channels/929487054990110771/929544565348777984/1016301559551893534

E.g. jest immutably caches the faker instance, thus two parralel test files will generate the exact same values, sometimes.
Calling faker.seed() early in the tests seems to fix the issue.

[codan84]

Just had a nice convo on discord regarding an issue of using faker with Jest.

The issue was faker returning duplicate values when calling faker.random.alphaNumeric:

1. When called multiple times in the same test file, all values would be unique
2. When called in multiple test files, values would be duplicated between test files in about 30% of runs

Simple way to replicate the issue - 2 test files and a module shared between them:

// helpers/random.ts
import { faker } from '@faker-js/faker'

export const getRandomSalesForceId = () => {
  return faker.random.alphaNumeric(18)
}
// ======

// test1.spec.ts
import { getRandomSalesForceId } from './helpers/random'

describe('some test 1', () => {
  test('some test 1', () => {
    const sfId = getRandomSalesForceId()
    console.log(`>>> some test 1 >>> ${sfId}`)

    expect(sfId).not.toBeNull()
  })
})
// ======

// test2.spec.ts
import { getRandomSalesForceId } from './helpers/random'

describe('some test 2', () => {
  test('some test 2', () => {
    const sfId = getRandomSalesForceId()
    console.log(`>>> some test 1 >>> ${sfId}`)

    expect(sfId).not.toBeNull()
  })
})
// ======

My suspicion is that this is due to Jest spinning up a pool of worker child processes and running each spec file in a separate worker. This would imply fresh instance of every module used by tests (including faker). If these were initialized close together we could run into an issue with the same seed used?

2 possible solutions found:

1. run jest with --runInBand option (https://jestjs.io/docs/cli#--runinband)
2. seed faker early in tests, for example:

// helpers/random.ts:
import { faker } from '@faker-js/faker'

faker.seed()

export const getRandomSalesForceId = () => {
  return faker.random.alphaNumeric(18)
}

// or directly in test:
import { faker } from '@faker-js/faker'

describe('some test', () => {
  beforeAll(() => {
    faker.seed()
  })
  
  test('some test', () => {
    // use faker
  })
})

Maybe worth adding to the abovementioned docs :)