-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feature request] Ability to define suite-level fixtures #19
Comments
Thanks for your input! Yes that's a feature which would come in handy if setup/tear-down costs are high. On the other hand you might risk leaking state from one test to another which wouldn't be that nice. There's also the issue with the ownership model of Rust which imposes some restrictions on the shared fixture, e.g., as the fixture data would be used by multiple tests a fixture might only immutable references to the data either in the form of an immutable borrow, an Rc, or an Arc. Further as Rust allows you to run tests in parallel (galvanic-test hinders parallelism a bit atm---which should change) the returned data should also be thread-safe (so no Rcs). Could you please elaborate what you want to achieve? Would sharing immutable data be enough? Would you like to use the same fixture in multiple suites (set up and torn down separately for each of them)? |
In my particular use case I just wanted to do some filesystem setup - create some directories and some read-only relative filepaths. These files could be shared between tests. So in my case, I think the only data I would need would be the name of the paths created - so an immutable reference would be fine. |
As for behavior in multiple suites - in my use case, I think either would be fine (ie, it's setup and torn down for each suite, or it's setup for the first suite that uses, and torn down for the last suite), though I suppose the latter behavior would effective make it a session-level fixture, not a suite-level one. So I suppose all I'm saying is that for me, either session or suite fixtures would be ok. I think suite would probably be more broadly useful, though. |
So more or less a |
I'd love the ability to define fixtures that are set up + torn down once for the entire test suite. This would be similar to setting the scope of a fixture to "class" for pytest fixtures (since you seem familiar with pytest).
The text was updated successfully, but these errors were encountered: