Skip to content
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

Open
wants to merge 3 commits into
base: devel
Choose a base branch
from
Open

Background support #2

wants to merge 3 commits into from

Conversation

mullr
Copy link
Contributor

@mullr mullr commented Jul 10, 2018

No description provided.

Russell Mull added 3 commits July 10, 2018 13:22
- 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()

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.

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)
// }

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dead code?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants