Closed ScottAwesome closed 1 year ago
I have had the same thought recently, and went ahead and made an implementation a few days ago, of "vitest-fixture" a package "on top of" Vitest, that provides an API very similar to the Playwright fixture feature:
https://www.npmjs.com/package/vitest-fixture
Please let me know if this would be useful for your use-case, and let me know if you have improvement suggestions!
I'd love to see this feature land in Vitest. @larsthorup 's package is good. But I think this would be a fantastic addition to vitest.
Let's discuss the API for this. Playwright's API is really battle tested and it evolved over the versions of playwright (was Folio previously). I've been watching the project evolve, and I think they landed in a nice API.
vitest-fixture
matches Playwright's API very closely so we could bake it in vitest core.
Thoughts?
I'd love to see this too. Makes typing and composing context much simpler, and I would hope an implementation would carry over Playwright's feature to smartly initialize fixtures based on usage.
This is a nice feature. If anyone is willing to implement it, PR is welcome :)
This is a nice feature. If anyone is willing to implement it, PR is welcome :)
This is cool! I would like to give it a try.
Clear and concise description of the problem
As a developer I'd love if the API for test context (fixtures) mirrored that of playwright test
This would be better for the following reasons:
beforeEach
before a test to modify its context. You could easily share customizedtest
/describe
and/orit
blocks. UsingbeforeEach
is clunky and not easily sharable.Suggested solution
Allow for test context to be set on the test function level, via
test
/it
, and/ordescribe
. e.g.Alternative
No response
Additional context
This is largely brought about because on my team of 24+ engineers we would like to be able to have standard patterns for faking data. One of the requirements when it comes to sharing API data is having fake datasets that can be re-used for testing and tested against schema so that can test that our validators work correctly. Its also the same fake data factory datasets used for our API test responses, and for data transformers, among other things. We really started to scale the
@playwright/test
approach well and our team is finding this API to be rather clunky by comparison, and having to declare a module augmentation adds more overhead and is prone to error.Validations