---
# System prepended metadata

title: ✅ Prisma Integration Tests

---

# ✅ Prisma Integration Tests

~~1. Set up vitest for running integration tests~~
~~2. Set up docker compose to spin up an instance of MongoDB~~
~~3. Have at least one example of Prisma integration test running in this new setup~~

# Isolated Preview Environments

1. Configure Preview Environments to have their own instance of MongoDB so tests can run in isolation
   - Where should the Mongo instances live? Atlas? What about pricing?
2. Seed Mongo with testing data. One idea is to use [replibyte](https://www.replibyte.com/docs/introduction) to extract obfuscated data from prod. The following config was used on some initial tests:

    ```
    source:
    connection_uri: mongodb+srv://xgrowthuser:CUBaBodIgAdaFOqr@cluster0.7crht.azure.mongodb.net/xGrowth
    transformers:
       - database: xGrowth
         table: users
         columns:
           - name: UserName
             transformer_name: email
           - name: email
             transformer_name: email
           - name: NormalizedEmail
             transformer_name: email
       - database: xGrowth
         table: invitenotifications
         columns:
           - name: emails.$[]
             transformer_name: email
    destination:
    connection_uri: mongodb://admin:admin@127.0.0.1:27017/xGrowth
    datastore:
    local_disk:
       dir: ./.data/replibyte
    ```


    Some other references:

    - https://docs.snaplet.dev/tutorials/prisma-seed/
    - https://www.prisma.io/docs/guides/migrate/seed-database


# Prisma Referential Actions

Currently, our Prisma schema does not configure [referential actions](https://www.prisma.io/docs/concepts/components/prisma-schema/relations/referential-actions), which means we may end up with data integrity issues if a record needed by another record is deleted.

Similar to FK in a relational DB, referential actions may help up keep a healthier dataset.

# Workspace Structure

In order to better implement NextJS community standards, the proposal is to organize our workspaces as follows:

```
growinco/
  - apps/
    - gasp/
    - petit/
    - platform/
  - packages/
    - date-utils/
    - ui/
    - service/
```

Keeping deployable applications within the `apps` scope while sharable packages would live under `packages`.

# Improved TypeScript Setup

It seems that out TS setup is throwing VSCode off when it comes to autocomplete suggestions. The idea is to set up TS per workspace having a common tsconfig file at the root to share configuration.

This may allow us to better target include/exclude statements to the needs of each workspace.

We can use [this vercel turborepo example](https://github.com/vercel/turbo/tree/main/examples/basic) as reference.

# CI/CD

Investigate/Implement [Github Actions integrated with vercel's workflow](https://vercel.com/guides/how-can-i-use-github-actions-with-vercel) so that:

1. Upon pushing to a PR branch;
2. A preview env is initialized with its own MongoDB instance;
3. Unit tests are run;
4. Integration and e2e (Cypress) test are run against that env;
5. Report results directly to the PR (Failed tests, test coverage, linting, etc...);

# DB Data Normalization

There are some models with array of id fields which make it hard to map relationships back in the Prisma schema, making simple queries a bit too complex for their own good.

We should try to tackle these instances one at a time, coverting them to actual relationships backed by Prisma. [Here's one example](https://github.com/orgs/GrowinCo/projects/2/views/15?pane=issue&itemId=27535880).