Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Cross-platform suite-local fixtures #104
Cross-platform suite-local fixtures #104
Changes from 1 commit
16899c4
38fc284
385d19d
1c5deba
d613c32
d9ffc91
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this is really my only question here. since there's no way to enforce backpressure between the release of the suite-local fixture and the acquisition of the next, you could run into some weird interactions between different suites. for example, if your fixture is a network server that binds to the same port. suite A might not release its port before the suite B attempts to acquire
I think this is still really useful for javascript to have, so this may just need to be a tradeoff that we warn users about
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm mindful of this issue too, but exactly as you said. For plenty of non-interacting resources should be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's particularly evil, but this problem could be solved via some sort of global semaphore right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds like it should work, but it would inhibit parallel suite execution (only the suites which use this feature) for users who opt in. which again may be fine and just something we warn users about
the fixtures do have names, so ideally you could split the global semaphore by name, but that relies on the assumption that interacting resources have the same name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, but on JS we don't have parallel execution anyway. So maybe the trick is to use this implementation for JS (plus some sort of global semaphore), your blocking implementation for JVM, and just provide them under the same interface?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should call it
UnsafeResourceSuiteLocalFixture
to emphasize these hazards.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im still a bit confused :)
We have a working
ResourceSuiteLocalFixture
for the JVM only. As far as I understand, you want to add similar functionality but for JS?I don't really know anything about ScalaJS and how to create libraries for it, but I don't get why we need to create something that works on both the JVM and JS?
Because, this shared logic on the JVM, doesn't really work as one would expect. And since we already have something that works the JVM, why add something shared?
So in my mind, that has no JS knowledge, can this logic simply be added to the JS part of this library? Or is there some value in having something shared?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good questions!
Yes, absolutely. If it is not shared, then if you want to test your code on both JVM and JS you'd have to write your tests twice, separately for each platform. For a concrete example of this consider the http4s test suite which now needs to support both JVM and JS platforms where in fact I've already been using this construct:
https://github.com/http4s/http4s/blob/main/testing/shared/src/test/scala/org/http4s/Http4sSuite.scala#L68
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then I would indeed go for the
UnsafeResourceSuiteLocalFixture
:)Does the
CatsEffectFunFixtures
not give you the functionality you desire?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CatsEffectFunFixtures
does work on JVM and JS, but it allocates/tears down the resource once per test. TheSuiteLocal
fixtures allocate/tear down once per suite.