-
-
Notifications
You must be signed in to change notification settings - Fork 770
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
Add support for passing a function to stub.throws(...) #1511
Add support for passing a function to stub.throws(...) #1511
Conversation
56ca44f
to
723c706
Compare
Looks good, but need to test it to get a feel for it :-) |
Nice work! I'm missing test cases verifying that the error object is now created lazily for all three cases. |
I added some tests, are those assertions what you were thinking of? |
9e423d9
to
bde1204
Compare
In general, yes. However, you're now testing the implementation details, not the behavior. I was thinking of asserting the point in time a given function is actually called, or stubbing the |
I see, I'll make the change |
bde1204
to
55c3f5f
Compare
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.
Think those tests look much better.
Great tests! Thank you very much 👍 |
This introduced regression #1526. Mind taking a look at it, @noisecapella? |
Yes I'll take a look |
Purpose (TL;DR) - mandatory
Fixes #1507
This PR adds functionality to allow
stub.throws(...)
to accept a function as an argument. This function is invoked at the point that the exception is thrown which allows the end user to have a more descriptive stack trace for the error. This also delays instantiating theError
until it is thrown (except when the user has already instantiated it) to create a more detailed stack trace.Background (Problem in detail) - optional
At least in node, the stack trace for an
Error
is created when the object is instantiated rather than when it's thrown (from here). The stack trace is sometimes useful in figuring out what pieces of code are involved with an error. Currently errors used inthrows(...)
are instantiated by the caller or soon after in the setup of the stub which results in a stack trace showing where the setup occurred rather than where the problem occurred.Solution - optional
In cases where the exception is not passed into
throws(...)
, a function which will instantiate the exception is used internally instead and assigned to a new fieldexceptionCreator
. When the exception is thrownexceptionCreator
is instantiated and the result is assigned toexception
to allow inspection viatoString
or other means.How to verify - mandatory
To see the difference in stack trace see the test I included in the linked issue.