Improving create-redwood-app Jest Unit Test Implementation

Note: this issue addresses testing implementation for create-redwood-app. For test and lint issues related to the redwoodjs/redwood repo, see #259

For background, see #152, specifically:

• https://github.com/redwoodjs/redwood/pull/152#issuecomment-592287624
• https://github.com/redwoodjs/redwood/pull/152#issuecomment-593835518

Current implementation of yarn rw test has the following limitations:

• locked into default 2 sides: api and web
• “locks” the required config flag into the command behind the scenes
• stores the respective jest.config…js files inside of package core/config/

Proposed improvements:

• map command to reference app workspaces to automatically include all sides
• make current required config transparent/known and allow user to override flag
• store config files either in App root or each side with respective config (see thoughts from Aspirational below)

Lastly, I took a stab at what would make for an awesome out-of-the-box testing experience in RWJS. Seems like the same integration problems that haunt JS ecosystem are especially painful when it comes to testing. Edit, revise, and comment away as helpful!

Aspirational: Making Unit Testing (via Jest) a First Class Citizen in RWJS

The current state of Webpack, Bable, ESLint, and React makes testing hard, which means fewer developers will implement testing and even fewer will sustain testing. Testing shouldn’t be a “nice to have”, it should be an accessible “must have”.

The Redwood experience allows developers to run meaningful, informative tests out of the box:

• bootstrapped CI using GHActions running lint and jest (and perhaps code coverage checks)
• test template files included in generators and scaffolding
• no additional config or setup required out of the box
• if additional config is needed, capability for simple config extension managed from either App root or specific to App sides (e.g. web/, api/, etc.).
• new App sides included automatically by test runners
• identical DX to development in Redwood at large, e.g. auto-imports, ESLint settings, etc.
• opinionated about library and best practices, which in our case is React Testing Library

[peterp]

store config files either in App root or each side with respective config (see thoughts from Aspirational below)

I’m trying to do as much of the heavy lifting inside of the Redwood packages because each file we include in create-redwood-app is a potential place that makes upgrading difficult.

I would also love to be “zero conf” and supportive of custom configuration through documentation where people can extend our existing configs (babel, webpack, eslint, and jest).

I’m 👍on figuring out a way to add more “sides” of certain “targets” (api, web, app, etc), since the targets drive what kind of configuration we need to apply.

[AryanJ-NYC]

Hey @thedavidprice!

Thanks for reaching out. I am quite interested in getting into the RedwoodJS infrastructure bit by bit. It truly is a beautiful fabric of technology (and some of my favorite technologies, at that!).

I’ve created #256 in thoughts that it alleviates the concerns by bullet points 1 and 3 in OP.

As for bullet 2, do you have any thoughts on how to: “make current required config transparent/known”?