-
-
Notifications
You must be signed in to change notification settings - Fork 231
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
Enable mocking of sticky modules (not used by code_server) #29
Conversation
Good stuff. I'd like to see an option I have not looked at using |
* Renamed the field originally_sticky to was_sticky * unsticking test module at end of test run Matt & Damon
Matt & Damon
code:is_sticky/1 returns false when the module is not yet loaded, even if it's in the kernel or stdlib.
I've updated the branch and pull request with your recommended changes, as well as fixing some pretty serious flaws in my first implementation. |
Great stuff. I had some more picky comments. :-) What happens when you don't use the What happens when you use the |
Let me know if you want to add the test cases I suggested. Otherwise I can pull it into a separate branch to add them myself. |
I spent a large part of yesterday trying to get these tests written and passing, with not a lot of luck. I can't seem to meaningfully trap any errors coming out of the gen_server part of meck, even if they're just caused by init/1 returning {error, Reason} - gen_server is turning that response into an exit, and I can't get a try/catch to work for that. I would greatly appreciate it if you could handle these last couple tests. |
Sure, I'll look at it as soon as possible. |
This is a quick patch for #7 that handles the simple case mentioned there (I.E., modules not in use by code_server).
Have there been any attempts to use erlang:load_module/2 as mentioned in the initial issue, or some other solution, to allow mocking the other affected modules, especially gen_server?
If not, I'd love to give it a try myself, but I'm not yet sure I understand quite where the erlang:load_module/2 call would fit into the system, and would love some discussion on the subject.
Thanks!