Stringify errors before processing #124
Conversation
|
Unfortunately, I haven't worked out a great way to test this change yet. The existing tests mostly check that things pass or fail as expected, but this will fail either way. The actual change is to what's collected in the failure, and I need to think on a non-brittle way to verify that there's a stack trace there. |
|
Since debug.traceback is subject to change at any time you might not be able to test a stack trace since you can't guarantee the form. You could always set up an object with an __tostring method that returns a certain string and then make sure the error contains that string at least somewhere inside it? |
| @@ -8,6 +8,9 @@ | |||
| * Limitations: | |||
| * `expect.extend` cannot be called from within `describe` blocks | |||
| * Custom matcher names cannot overwrite pre-existing matchers, including default matchers and matchers introduces from previous `expect.extend` calls. | |||
| * Change the way errors are collected to call tostring on them before further processing. | |||
| * Luau allows non-string errors, but not concatenating non-strings or passing non-strings to `debug.traceback` as a message, so TestRunner needs to do that step. This is a temporary fix as the better solution would be to retain the error in object form for as long as possible to give the reporter more to work with. | |||
| * This also makes a slight change to what's in the traceback to eliminate the unnecessary line mentioning the error collection function. | |||
| @@ -196,7 +196,9 @@ function TestNode:expand() | |||
| end | |||
| setfenv(self.callback, callbackEnv) | |||
|
|
|||
| local success, result = xpcall(self.callback, debug.traceback) | |||
| local success, result = xpcall(self.callback, function(message) | |||
| return debug.traceback(tostring(message), 2) | |||
There was a problem hiding this comment.
Nitpick: Might be good to later move this debug.traceback snippet into its own modules for the sake of making sure we keep it DRY, esp since we're passing in "magic" scope
There was a problem hiding this comment.
There's probably several such utility functions that could be pulled out.
Since Luau allows non-string errors (e.g.
error({})), TestEZ needs to handle those. At the moment, it will try and concatenate the error with the rest of the message, which will fail, which will cause it to not output a stack trace. This callstostringon any errors before further processing.Closes #122