feat: Add Bamboo.TestAdapter.forward/2 #620
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This provides a way to receive emails from other processes without resorting to shared mode and synchronous tests. For background, this builds on some work that I did to allow Wallaby tests to play nicely with Mox, while still allowing the tests to be async. I wrote about it here: https://jonleighton.name/2021/asynchronous-browser-tests-with-phoenix/ And then contributed some docs to Wallaby about the setup here: elixir-wallaby/wallaby#592 This commit basically implements a kind of Mox.allow/3 function for Bamboo.TestAdapter. Note that I’ve changed the order of the arguments for this Bamboo.TestAdapter.forward/2 function. For Mox.allow/3, the owner_pid comes first: Mox.allow(MyMock, owner_pid, child_pid) But for Bamboo.TestAdapter.forward/2, the child_pid comes first: Bamboo.TestAdapter.forward(child_pid, owner_pid) My reasoning is that in the first example we’re allowing the child_pid to access mocks defined by the owner pid. But in the second example, we’re forwarding emails FROM the child_pid TO the owner_pid. So this order of arguments seemed to make sense to me, but may be slightly confusing.
|
Thanks for opening this PR @jonleighton! I really like the idea of what you're doing here. I'll try to find some time later this week to give it a good review. |
|
Hi @jonleighton! Now that BEAM Community is taking over Bamboo we're working through these older PRs. Are you interested in pursuing getting this PR merged? If so, it might be good to review Bamboo and see if any additional changes are necessary now that this PR is 3 years old. |
doomspork
changed the title
|
This pull request has been automatically marked as "stale:discard". If this pull request is still relevant, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize reviewing it yet. Your contribution is very much appreciated!. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This provides a way to receive emails from other processes without
resorting to shared mode and synchronous tests.
For background, this builds on some work that I did to allow Wallaby
tests to play nicely with Mox, while still allowing the tests to be
async. I wrote about it here:
https://jonleighton.name/2021/asynchronous-browser-tests-with-phoenix/
And then contributed some docs to Wallaby about the setup here:
elixir-wallaby/wallaby#592
This commit basically implements a kind of Mox.allow/3 function for
Bamboo.TestAdapter.
Note that I’ve changed the order of the arguments for this
Bamboo.TestAdapter.forward/2 function. For Mox.allow/3, the owner_pid
comes first:
But for Bamboo.TestAdapter.forward/2, the child_pid comes first:
My reasoning is that in the first example we’re allowing the child_pid
to access mocks defined by the owner pid. But in the second example,
we’re forwarding emails FROM the child_pid TO the owner_pid. So this
order of arguments seemed to make sense to me, but may be slightly
confusing.