Redwood fixtures or factories for testing?

How do you unit-test prisma-client resolvers?

Question I have asked myself for couple days now. I know prisma is widely used in node.js community but it was hard finding any straight forward answers that’s satisfied me should I say and it’s actually quite confusing too and not as nearly as easy as testing controllers in ruby on rails.

Here is bunch of examples I manage to gather from my digging around the prisma repo,

https://github.com/divyenduz/prisma-faker-example

One thing I have notice by all of these examples is that. There has to be something similar to fixtures in rails Testing Rails Applications — Ruby on Rails Guides Fixtures are a way of populating your “test database” not the real one. Here is a simple ruby example

require 'test_helper'

class UsersControllerTest < ActionDispatch::IntegrationTest

  def setup
    @user = users(:user)
  end

  test "should update user" do
    patch user_path(@user), params: { user: { name: "joe", surname: "bob" }}
    
    reload
    assert_equal "joe", @user.name
    
    assert_redirected_to root_url
    assert_not flash.empty?
  end

end

Note that @user.name is the fixtures from the test database. That’s the only I can think of testing methods like find() and findMany() there has to be a way of comparing records in a test database. Then you can make comparison and assertions and write a test case funny things is prisma does actually have something similar to this,

import { PrismaClient } from '@prisma/client'
// Here is the seed
import seed from '@prisma/test-utils/seed'
import SQLitePool, { Pool } from '@prisma/test-utils/pool'

describe('blog:', () => {
  let pool: Pool

  beforeAll(async () => {
    pool = new SQLitePool({
      pool: {
        max: 5,
      },
    })
  })

  afterAll(async () => {
    await pool.drain()
  })

  test('creates blog', () =>
    pool.run(async db => {
      const client = new PrismaClient({
        datasources: {
          db: db.url,
        },
      })

      await seed({
        client,
        models: kit => ({
          '*': {
            amount: 5,
          },
          Blog: {
            factory: {
              name: kit.faker.sentence,
              posts: {
                max: 1,
              },
            },
          },
        }),
      })

      /* Query authors. */
      const authors = await client.author.findMany()

      expect(authors).toMatchSnapshot()

      /* Disconnect the client. */
      client.disconnect()
    }))
})

Maybe if redwood shipped with some wrappers around it or helpers because as usual with javascript there is heck a lot boilerplate code you have to write just to setup it up?

@rob @thedavid What do you guys think?

I’m all about fixtures in Rails but I know @mojombo has some misgivings. We haven’t really sat down as a group and discussed what we’re going to do about testing prisma-based things. If he gets a moment he might be able to jump on this thread and give his thoughts.

I do agree that if we went the route you suggested we’d hide as much boilerplate as possible in Redwood internals so you can just get to the good stuff of testing.

I was wondering if in the meantime something has been created to make this easier? Or are there new insights in how this might be done in a real world example?

We’ve got a PR that adds fixtures (we’re calling them “scenarios”): https://github.com/redwoodjs/redwood/pull/1465

You can read about the usage in the beta of part 2 of the tutorial: https://deploy-preview-421--redwoodjs.netlify.app/tutorial2/adding-comments-to-the-schema#testing-the-service