-
Notifications
You must be signed in to change notification settings - Fork 50
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
feat: match multiline error #200
Conversation
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
----
An example generated by |
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.
(Haven't reviewed yet) @wangrunji0408 requested multi line mode for query last time (To test select jsonb_pretty
). Could the work for these two features be shared?
forget it
@@ -102,8 +101,7 @@ pub enum Record<T: ColumnType> { | |||
label: Option<String>, | |||
/// The SQL command is expected to fail with an error messages that matches the given | |||
/// regex. If the regex is an empty string, any error message is accepted. | |||
#[educe(PartialEq(method = "cmp_regex"))] | |||
expected_error: Option<Regex>, | |||
expected_error: Option<ExpectedError>, |
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.
First I'm thinking whether it's necessary to introduce the error enum. Why not put it in expected_results
. But it should be problematic.
I think we've messed the Record
type. 🤣 To be more correct, it should be like enum of error or results. Some fields are common, and some belong only to query.
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.
nvm. I'm happy to live with it.
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.
Same opinion with you. 😕 It's a sum type instead of a product type. We may refactor them in future PRs.
} | ||
|
||
/// Returns whether the given error message matches the expected one. | ||
pub fn is_match(&self, err: &str) -> bool { |
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.
pub fn is_match(&self, err: &str) -> bool { | |
pub fn matches(&self, err: &str) -> bool { |
?
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.
This is how regex
names. 😕 Just to keep interface unchanged.
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.
LGTM. Just some minor points
@skyzh @wangrunji0408 can we add @BugenZhao as a colaborator. |
Yep let's do that! |
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Wow, |
@xxchan Would you please release a new version for this? 🥰 |
@BugenZhao Done |
Support matching multiline error message under
----
for bothstatement error
andquery error
.The output error message must be the exact match of the expected one to pass the test, except for the leading and trailing whitespaces. Users may use
--override
to let the runner update the test files with the actual output.Empty lines are allowed in the expected error message. As a result, the message must end with two consecutive empty lines.
Breaking changes in the parser:
ParseErrorKind
. Mark it as#[non_exhaustive]
.expected_error
fromRegex
toExpectedError
, which is either a inlineRegex
or multilineString
.