Re-evaluate Wasp's testing story

Martinsos commented 6 months ago

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?

Parts of this are covered in https://github.com/wasp-lang/wasp/issues/2232

Martinsos commented 3 months ago

sodic commented 3 months ago

When dealing with this, we should also document our advice on structuring the server code for easier testing:

We've mostly been telling users to structure their code so that most of their business logic takes place in other functions (not the operation). In other words, it's best to make your operations as short as possible, and do all the "smart things" in subroutines that you can then test (and mock). This is still a valid suggestion.

A user found this helpful and suggested to include it in the docs (source).

Martinsos commented 3 months ago

When dealing with this, we should also document our advice on structuring the server code for easier testing:

We've mostly been telling users to structure their code so that most of their business logic takes place in other functions (not the operation). In other words, it's best to make your operations as short as possible, and do all the "smart things" in subroutines that you can then test (and mock). This is still a valid suggestion.

A user found this helpful and suggested to include it in the docs (source).

I wouldn't advise this so strongly though, so as not to over-complicate things for the users that don't need that level of separation. I would say that if user knows enough about writing tests, they should be able to also figure out on their own that they can extract logic into a testable function. We might advise it as a way to go, but maybe not so strongly as to say in a prominent place in docs that they should always keep it all extracted. To avoid complicating things for begginers also. We should also probably look to possibly allow for testing operations without having to that kind of extract, if it is possible in a reasonable manner.

wasp-lang / wasp

Re-evaluate Wasp's testing story #2049