feat: match multiline error #200
Conversation
Signed-off-by: Bugen Zhao <i@bugenzhao.com>
Signed-off-by: Bugen Zhao <i@bugenzhao.com>
Signed-off-by: Bugen Zhao <i@bugenzhao.com>
BugenZhao
changed the title
----
|
An example generated by |
There was a problem hiding this comment.
(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.
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.
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.
| pub fn is_match(&self, err: &str) -> bool { | |
| pub fn matches(&self, err: &str) -> bool { |
?
There was a problem hiding this comment.
This is how regex names. 😕 Just to keep interface unchanged.
|
@skyzh @wangrunji0408 can we add @BugenZhao as a colaborator. |
Yep let's do that! |
Signed-off-by: Bugen Zhao <i@bugenzhao.com>
Signed-off-by: Bugen Zhao <i@bugenzhao.com>
Signed-off-by: Bugen Zhao <i@bugenzhao.com>
|
Wow, |
|
@xxchan Would you please release a new version for this? 🥰 |
|
@BugenZhao Done |
Support matching multiline error message under
----for bothstatement errorandquery 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
--overrideto 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_errorfromRegextoExpectedError, which is either a inlineRegexor multilineString.