Testing & Scenarios : what about standard, multiple scenarios and different needs

Get Help and Help Others
1

I’m currently testing the whole testing part of RW within a project with a consequent codebase.
I began with something easy, the user related endpoints, here’s the code:

import random from 'random'
import { createCustomerUser, createRestaurateurUser, updateUser } from './users'

function mockUser() {
  const randId = random.int(999, 10000)
  return {
    handle: `Bob #${randId}`,
    firstname: 'Bob',
    lastname: `McBot${randId}`,
    slug: `bot.Bob#${randId}`,
    email: `bot${randId}@teamredacted.com`,
  }
}

describe('users', () => {
  scenario('Endpoint - Creates a new Customer User.', async () => {
    const input = mockUser()
    const user = await createCustomerUser({ input })
    expect(user).toMatchObject(input)
  })

  scenario('Endpoint - Creates a new Restaurant User.', async () => {
    const input = mockUser()
    const user = await createRestaurateurUser({
      input: { ...input, name: input.handle },
    })
    expect(user).toMatchObject(input)
  })

  scenario('Endpoint - Update a scenario created User.', async (scenario) => {
    const u = await updateUser({
      id: scenario.user.bob.id,
      input: { firstname: 'JustBot' },
    })
    expect(u.firstname).toMatch('JustBot')
  })
})

I use a custom mockUser here to make sure I actually create the user myself using the endpoints - and not by relying on *.scenarios.js.

The tests work well until the scenario “Endpoint - Update a scenario created User.”, which is the first one relying on the actual users.scenarios.js. If I define a scenario, all my users.tests fail, including those which were working previously.
If I don’t define scenario datas, I can’t update a user.

So it seems to me that the issue is if I define scenario datas, it executes for the entire module, leading to the following errors:

FAIL   api  api/src/services/users/users.test.js (11.484 s)
  ● users › Endpoint - Creates a new Customer User.


    Invalid `prisma.user.create()` invocation:


      Unique constraint failed on the fields: (`email`)

      at PrismaClientFetcher.request (../node_modules/@prisma/client/runtime/index.js:79355:15)
      at seedScenario (../node_modules/@redwoodjs/core/dist/configs/node/jest.setup.js:60:34)
      at Object.<anonymous> (../node_modules/@redwoodjs/core/dist/configs/node/jest.setup.js:130:26)

  ● users › Endpoint - Creates a new Restaurant User.


    Invalid `prisma.user.create()` invocation:


      Unique constraint failed on the fields: (`email`)

      at PrismaClientFetcher.request (../node_modules/@prisma/client/runtime/index.js:79355:15)
      at seedScenario (../node_modules/@redwoodjs/core/dist/configs/node/jest.setup.js:60:34)
      at Object.<anonymous> (../node_modules/@redwoodjs/core/dist/configs/node/jest.setup.js:130:26)

  ● users › Endpoint - Update a scenario created User.


    Invalid `prisma.user.create()` invocation:


      Unique constraint failed on the fields: (`email`)

      at PrismaClientFetcher.request (../node_modules/@prisma/client/runtime/index.js:79355:15)
      at seedScenario (../node_modules/@redwoodjs/core/dist/configs/node/jest.setup.js:60:34)
      at Object.<anonymous> (../node_modules/@redwoodjs/core/dist/configs/node/jest.setup.js:130:26)

Thanks to my schema.

Question
Is there a way to target to which scenario the scenario data should be made available to? Maybe through the use of a constant named other than standard?

Remark
I could separate my tests in different testing modules based on their use of this or that scenario, having one for creation endpoints and one for edition/deletion endpoints, but it doesn’t feel as elegant as it should.

Anyway, any input on the matter would be greatly appreciated :).

1 Like
2

^^ @rob as our new TestOverlord9000™, this one’s for you!

3

Since I’m facing new challenges with scenarios I came back here and can report:
I’ve changed my workflow, first I execute tests that don’t require mockCurrentUser or scenarios, then I move on to tests that would require them.

That makes things a bit clearer to organise tests in this way as it saves some headaches, however questions remain about scenarios and their flexibility.

If any-@rob has some input on this :stuck_out_tongue: that would be great \o/

1 Like