Before, it wasn't easy to test external Wasp code due to how Wasp projects were organized.
Which is why we added special support for writing tests for frontend, to enable that. We wanted to do the same thing for backend, but didn't yet get there.
Now, after big Wasp restructuring, Wasp projects are proper npm packages with package.json and defining unit/integration tests for user's code is easier and they have quite some flexibility -> so no special support from our side is needed anymore for users to be able to write tests for frontend/backend.
We also added e2e tests to multiple projects, including open-saas, so those can be also set up independently of Wasp even.
Things we should do:
[ ] Explore and document what testing experience with Wasp looks like at the moment: client, server, shared, unit, integration, e2e. How hard is mocking, how hard is it to set up the tests, ... .
[ ] Figure out how we can make the experience smoother / better, and provide what we can to make that so. That might be just docs, or examples, or some scaffolding, or some utility libraries for mocking, ... .
[ ] What about that special support for frontend tests we had before? That is not needed anymore I guess? Have we dropped that after restructuring? If we haven't yet, should we?
Before, it wasn't easy to test external Wasp code due to how Wasp projects were organized. Which is why we added special support for writing tests for frontend, to enable that. We wanted to do the same thing for backend, but didn't yet get there.
Now, after big Wasp restructuring, Wasp projects are proper npm packages with package.json and defining unit/integration tests for user's code is easier and they have quite some flexibility -> so no special support from our side is needed anymore for users to be able to write tests for frontend/backend.
We also added e2e tests to multiple projects, including open-saas, so those can be also set up independently of Wasp even.
Things we should do: