-
Notifications
You must be signed in to change notification settings - Fork 3
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
Background support #2
base: devel
Are you sure you want to change the base?
Conversation
- Use common parser definitions from parse_utils - Factor out an eol() parser into parse utils to match either newline or eof.
Previously, TestCase was a trait, and features were composed of boxed TestCase trait objects. This changes it to an enum, since we expect to have only a small number of TestCase types, and users are not expected to provide new ones. This also changes the module layout; previously, the scenario and feature parsers and AST structs were each in their own modules. This makes less sense when using the enum at the TestCase level. Now all the AST structs are in the AST module, and the parsers are in the parser module.
This adds support for a Background section in the spec, which is executed before each test case to initialize its context. - Add a TestResult struct, used at the TestCase level to bundle together success, the test case name, and the test context.
return TestResult { | ||
test_case_name: match self.name.as_ref() { | ||
Some(s) => s.clone(), | ||
None => "".to_string() |
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.
I'm not sure what is more idiomatic, but in cases like this I usually use String::new()
} | ||
|
||
/// A specific step which makes up a scenario. Users should create their own | ||
/// implementations of this trait, which are returned by their step parsers. |
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.
For rustdoc, I think the first line is supposed to be a summary of the functionality and then more details get added after a blank line. I think so it renders nicer?
// "#; | ||
|
||
// assert!(true) | ||
// } |
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.
Dead code?
No description provided.