Replies: 3 comments 6 replies
-
Yea I had the same feeling about this when updating the project, think it's a good idea to do the E2E testing differently. The original examples could also be run independently and even though the idea behind that is awesome I don't think a lot off ppl do this. Some things I think we could do:
Off topic regarding mercurius: I'm now running this project btw with no problems with nestjs + mercurius :) |
Beta Was this translation helpful? Give feedback.
-
Well you already did the main tedious job :) splitting updating and migrating to a more monorepo package manager. We could leverage this ? What matter is to not loose the substance of what has been tested (the initial package owner did an amazing job.) But it's true that this dos not help in context reproduction (as of now) What could help is having server context splitted in package (only the mains.ts and app.ts would changes) and splitting the server init from the tests. (Well having real e2e at the end of the day.) Is this proposal to your liking? |
Beta Was this translation helpful? Give feedback.
-
Congratz for the mercurius integration :) did you see some perf improvement? (Has it should) Did you have any problem with errors response format ? |
Beta Was this translation helpful? Give feedback.
-
I was starting to fiddle a bit with fastify plateforme with (ground work to support mercurius, but let's go slowly about this)
And found myself duplicating each example contexte with the exact same test in it. Not sur if this is the proper way. Only the before and after each changes.
What is your pick on this ?
(So fare all green by the way)
Beta Was this translation helpful? Give feedback.
All reactions