Open ggwadera opened 3 years ago
I'm glad to see progress is getting made on this issue. Last week I had mentioned how switching to the getLayout
pattern interfered with our current tests and I thought next-page-tester might be a good solution. After reading this little blog post https://dev.to/toomuchdesign/dom-testing-next-js-applications-46ke it sounds like the real solution is to switch to intergration tests like this and possible impliment some e2e tests as well.
Yeah some e2e tests running the entire Next.js stack might be good too, so we can test the SSG and SSR rendering with Next's data fetching and also the API layer. But for the front-end components I believe most cases can be covered by the unit tests.
With E2E tests we could test an entire flow of our app's logic, for example: account creation -> login -> send submissions -> receive review -> complete lesson. That might help in detecting some regressions like we already had before. But on the other hand, e2e tests are much harder to write.
I think we can cover most of our test cases with only the API layer of Apollo Server + Prisma. But for some corner cases the E2E tests might be the best solution though.
Sample PR for reference: https://github.com/garageScript/c0d3-app/pull/992
Since a lot of production breaking bugs have been happening recently due to failures that can't be caught with unit testing, writing integration tests to assure full API/client functionality can help in reduce the number of these bugs.
Basic implementation steps:
This will probably be better implemented using a in-memory embedded database like SQLite to avoid connecting to an external database, the recent Prisma seed PR #659 can help in seeding this db with fake data for the tests.