-
Notifications
You must be signed in to change notification settings - Fork 355
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
feat(stdlibs/std)!: change TestSetPrevRealm to TestSetRealm #2164
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2164 +/- ##
==========================================
+ Coverage 49.12% 49.16% +0.04%
==========================================
Files 576 577 +1
Lines 77805 77583 -222
==========================================
- Hits 38219 38145 -74
+ Misses 36495 36358 -137
+ Partials 3091 3080 -11
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
I like the new API that takes a struct and fixes the expected behavior. However, I'm worried about the name. Shouldn't |
Updated OP to better describe reasoning |
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 not super familiar with this API, but it's looks great too me 👍
…2164) This PR removes the `TestSetPrevRealm` and `TestSetPrevAddr`, added in gnolang#890, in favour of a new API `TestSetRealm`, which is more flexible in its behaviour. The function works by setting the result of `CurrentRealm()` for the frame in which the `TestSetRealm` function is called. Consequently, calling `PrevRealm` in any function called within will yield the value passed to `TestSetRealm`. `TestSetRealm` allows to transparently set "user" and "code" realms, by using two new costructors in the testing stdlibs, `std.NewUserRealm` and `std.NewCodeRealm`, allowing emulation of both kinds of callers. The call is not `TestSetPrevRealm` as it does not permanently "set" the value returned by PrevRealm, as if in a mock; it simply changes the Realm of the current frame, allowing "deep" calls to PrevRealm() to correctly return the value of the previous realm. <details><summary>Contributors' checklist...</summary> - [ ] Added new tests, or not needed, or not feasible - [ ] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [ ] Updated the official documentation or not needed - [ ] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [ ] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>
This PR removes the
TestSetPrevRealm
andTestSetPrevAddr
, added in #890, in favour of a new APITestSetRealm
, which is more flexible in its behaviour.The function works by setting the result of
CurrentRealm()
for the frame in which theTestSetRealm
function is called. Consequently, callingPrevRealm
in any function called within will yield the value passed toTestSetRealm
.TestSetRealm
allows to transparently set "user" and "code" realms, by using two new costructors in the testing stdlibs,std.NewUserRealm
andstd.NewCodeRealm
, allowing emulation of both kinds of callers.The call is not
TestSetPrevRealm
as it does not permanently "set" the value returned by PrevRealm, as if in a mock; it simply changes the Realm of the current frame, allowing "deep" calls to PrevRealm() to correctly return the value of the previous realm.Contributors' checklist...
BREAKING CHANGE: xxx
message was included in the description