change: Throw ParserException if file ends with tags #313
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For parity with cucumber/gherkin, do not accept feature files that end with `@tags` with no subsequent content. cucumber/gherkin is relatively permissive about incomplete files in some cases (for example, it is explicitly valid to have a file with a Feature: but no scenarios, or a Scenario: with no steps). I suspect this is intentional to avoid parser errors while iterating on a feature. However, the presence of `@tags` at the end of the file is unusual and suggests that the file is incomplete or damaged. cucumber/gherkin treats this as an exception and so should we.
acoulton
commented
May 5, 2025
Comment on lines
-51
to
+63
| $parser->parse( | ||
| <<<'FEATURE' | ||
| Feature: | ||
| Scenario: | ||
| Given step | ||
| @skipped | ||
| FEATURE | ||
| ); | ||
| try { | ||
| $parser->parse( | ||
| <<<'FEATURE' | ||
| Feature: | ||
| Scenario: | ||
| Given step | ||
| @skipped | ||
| FEATURE, | ||
| ); | ||
| } catch (ParserException $e) { | ||
| // expected - features cannot end with tags | ||
| $this->assertSame('Unexpected end of file after tags on line 5', $e->getMessage()); | ||
| } |
There was a problem hiding this comment.
This test relied on us parsing tags at the end of a file, but I don't think that was expected end-user behaviour. It was simply to prove that the parser state resets correctly on moving to the next file, and since we already know that tags are reset between features / scenarios / etc, the test had to create an artificial case where the tag was not attached to any node.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #313 +/- ##
============================================
+ Coverage 96.21% 96.23% +0.01%
- Complexity 596 598 +2
============================================
Files 35 35
Lines 1745 1751 +6
============================================
+ Hits 1679 1685 +6
Misses 66 66
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
carlos-granados
approved these changes
May 6, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For parity with cucumber/gherkin, do not accept feature files that end with
@tagswith no subsequent content.cucumber/gherkin is relatively permissive about incomplete files in some cases (for example, it is explicitly valid to have a file with a Feature: but no scenarios, or a Scenario: with no steps). I suspect this is intentional to avoid parser errors while iterating on a partially-complete feature file.
However, the presence of
@tagsat the end of the file is unusual and suggests that the file is incomplete or damaged. cucumber/gherkin treats this as an exception and so should we.