-
-
Notifications
You must be signed in to change notification settings - Fork 81
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
Allow for assertions against intentional non-match #705
Conversation
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.
Great stuff! Will be really nice to be able to record this type of test. Left a bunch of minor comments
- Don't forget to add note to docs
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.
Almost there! Left another round of feedback
…ursorless into wsommers/error-recorder
src/testUtil/TestCase.ts
Outdated
/** The final state after a command is issued. Undefined if we are testing a non-match(error) case. */ | ||
finalState?: TestCaseSnapshot; | ||
/** Used to assert if an error has been thrown. */ | ||
errorName?: ThrownError; |
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.
rename to thrownError
src/testUtil/TestCaseRecorder.ts
Outdated
@@ -248,7 +257,6 @@ export class TestCaseRecorder { | |||
// command for a navigation map test | |||
return; | |||
} | |||
|
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.
re-add
What?
This PR adds the ability to capture errors and non-matches from issued commands in the integration tests.
Why?
I wasn't able to do this as part of the TS-Scheme query PR and so added unit tests. I think it would be nice to have both. Non-matches help describe a complete spec of how expected behavior and unexpected behavior should be handled.
How?
finalState
instead recorderrorReturned
as a booleanerrorReturned
is present on the fixture, ensure we throwTodo
errorReturned
richer? I don't want to assert on an error message but I wonder if there is information that we can record to make the test cases more valuable.