TO READ:

https://github.com/prisma/prisma/discussions/4655#discussioncomment-301042

https://dev.to/eddeee888/how-to-write-tests-for-prisma-with-docker-and-jest-593i

https://stackoverflow.com/questions/62105729/run-jest-tests-in-docker-compose-with-mongodb-and-redis

prisma mocking

https://github.com/prisma/prisma/issues/5014

https://github.com/prisma/prisma/discussions/2083

https://github.com/marchaos/jest-mock-extended

https://github.com/prisma/prisma-test-utils

prisma1

https://github.com/prisma/prisma1/issues/3898

express request response

https://codewithhugo.com/express-request-response-mocking/

https://stackoverflow.com/questions/57964299/mocking-express-request-with-jest-and-typescript-using-correct-types

e2e api testing with database running

https://www.freecodecamp.org/news/end-to-end-api-testing-with-docker/

probably if were going to do testing in github actions while building the docker image it would make sense to then not build the same image when deploying on heroku

we could push to the DockerHub container registry since its open source and then heroku.yml would only pull that image?

https://devcenter.heroku.com/articles/container-registry-and-runtime#using-a-ci-cd-platform

https://github.com/fire-ci/tuto-api-e2e-testing

despite having an actual db and redis we should still mock external apis like tmdb and github to not rely on external infrastructure for our tests

https://stackoverflow.com/questions/58200327/how-can-i-run-a-docker-hub-container-on-heroku-via-app-json

https://stackoverflow.com/a/53522670/10854888

we need to run different jest tests depending on whether we have the database and redis available or not

https://medium.com/coding-stones/separating-unit-and-integration-tests-in-jest-f6dd301f399c

https://stackoverflow.com/questions/42303812/how-to-separate-unit-and-integration-long-running-tests-on-jest

github actions + docker:

https://github.community/t/how-to-use-docker-compose-with-github-actions/16850/6

https://github.com/stefanwalther/sense-navigation/blob/master/docker-compose.e2e-tests.yml

cypress + nextauth

https://next-auth.js.org/tutorials/testing-with-cypress

https://github.com/lirantal/cypress-social-logins/blob/6109f5ccef2f6961209e8063e9d4e664a5168a0b/src/Plugins.js#L276-L299

data-test-id

https://kentcdodds.com/blog/making-your-ui-tests-resilient-to-change

https://www.npmjs.com/package/babel-plugin-react-remove-properties

https://reactjs.org/docs/testing-recipes.html#mocking-modules

PLAN

1. Spin up a Docker container with Postgres and Redis.
   • it is unclear whether the web container should be running straight on ubuntu in Github Actions or also in Docker...
     • seems like there is no way to "run docker directly" on github actions
       • just run docker-compose etc.
     • maybe in Docker caching will be built in and it will be faster a bit maybe
       • if so then we should use the builder stage and not the production stage (Dockerfile)
     • maybe we could then develop this into publishing the built container images so that Heroku could use those same images!
2. First run Cypress tests that log in / sign up as two different users. Somehow save the cookies from these two users somewhere on disk.
   • maybe write them to stdout, stderr?
     • we have a database for something dont we 🤦‍♂️
   • this is because I have no idea how to do this with pure api calls... it may be possible but is ultimately pointless and we'd need to setup cypress eventually so this isn't that big of a deal
   • also we're going to need to store two github account credentials in secrets somehow for testing purposes
3. Run Jest integration/e2e tests which now thanks to having session/cookies data can call api endpoints as if from the browser.
   • we dont test that from cypress as the design of the website can still change drastically so no point in writing tests that are going to be needed to be rewritten imo

Unit tests should be able to run whenever without database, redis or a running server, so they may be theoretically done in parallel to integration tests etc. The integration and e2e tests have the problem of synchronizing database access (sql transactions?) as tests are made and data is written and deleted from db unexpected stuff may happen idk.