-
Notifications
You must be signed in to change notification settings - Fork 44
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
:var
does not seem to work with dynamic vars
#127
Comments
I think the analysis is as follows: since buttercup relies on lexical scoping, the But then the functions are simply run in a loop from somewhere else and the dynamic scope is no longer extended there. Yea, not quite sure what to do here, but a feature to modify dynamic scope would be very very rad. |
In the meantime, it might be prudent to have |
Buttercup doesn't work without lexical binding, this is documented in two places in doc/writing-tests.md. So a global error for disabled lexical binding seems more appropriate. |
Signal an error if the :Var or :var* keyword is found in any other position than the first argument of a describe macro. Fixes jorgenschaefer#223. There are several issues with the :var(*) keywords, the most important being it's inability to handle dynamic variables (jorgenschaefer#127). But there is also the question of what the correct behaviour would be if you use multiple :var(*) or when they are put anywhere but at the beginning of the describe macro.
Signal an error if the :var or :var* keyword is found in any other position than the first argument of a describe macro. Fixes jorgenschaefer#223. There are several issues with the :var(*) keywords, the most important being it's inability to handle dynamic variables (jorgenschaefer#127). But there is also the question of what the correct behaviour would be if you use multiple :var(*) or when they are put anywhere but at the beginning of the describe macro.
I was trying to do something like this: for each spec set a dynamic variable to a test mock value. I can't use
before-each
andsetq
because that would modify the global state forever.However, emacs allows
let
binding a dynamic variable and that should then work for all the code called in that scope (dynamic).I would therefore expect this to work, but the test fails. I think the
it
form is called in a different "dynamic" environment than the describe. I'm not sure if this can be somehow reconsiled. A "work around" is tolet
bind the variable in theit
forms but this leads to major duplication (I have 20-40it
forms for eachdescribe
)Maybe there could be some other mechanism to do this, like an
unwind-protect
that would set and re-set the variables but this would need a different keyword or notation.There's also the useful idiom to preserve a value of a special variable, for example
kill-ring
like soThe
whatever-here
code can do whatever but the global state of thekill-ring
will be preserved when it returns. This is quite useful in tests also. This would also be possible if:var
worked like this, i.e. preserved the "call stack" and dynamic lookup.The text was updated successfully, but these errors were encountered: