cucable is not picking the tags on example tables
Srinivasaraor opened this issue · 3 comments
Describe the bug
Cucumber allows tags on multiple example table for a scenario outline but cucable is not able to pick test value from example table based on tag
To Reproduce
Steps to reproduce the behavior:
@jurriespoelstra
- Scenario Outline: Check for Top Practice Areas and Jursidiction for an Expert Witness
Given a new request is created for the "test" user and "profilesuite" user
And the "Accept" header is set to "application/atom+xml"
And the path parameter "entityId" is "1234"
When the "GET" request is called for "PROFILE_S"
Then the response code is "200"
And the response body contains following text:
| <chart_tag> |
@regression
Examples:
| chart_tag |
| Case Experience by Area of Law |
@v1-s-1234 @Sprint-2 @rx.x
Examples:
| chart_tag |
| Case Experience by Jurisdiction |
- Run Cucable
- See error
Expected behavior
A clear and concise description of what you expected to happen.
Attachments
If applicable, add an attachment to help explain your problem.
Additional context
Add any other context about the problem here.
Hello @Srinivasaraor ,
I ran your example...
...without any <includeScenarioTags>
=> 2 features were generated:
# language: en
Feature: Test
@Regression
Scenario: Check for Top Practice Areas and Jursidiction for an Expert Witness
Given a new request is created for the "test" user and "profilesuite" user
And the "Accept" header is set to "application/atom+xml"
And the path parameter "entityId" is "1234"
When the "GET" request is called for "PROFILE_S"
Then the response code is "200"
And the response body contains following text:
|Case Experience by Area of Law|
# Source feature: src/test/resources/features/Karalljo.feature
# Generated by Cucable
-------------------------------------------------------------------
# language: en
Feature: Test
@v1-s-1234
@sprint-2
@rx.x
Scenario: Check for Top Practice Areas and Jursidiction for an Expert Witness
Given a new request is created for the "test" user and "profilesuite" user
And the "Accept" header is set to "application/atom+xml"
And the path parameter "entityId" is "1234"
When the "GET" request is called for "PROFILE_S"
Then the response code is "200"
And the response body contains following text:
|Case Experience by Jurisdiction|
# Source feature: src/test/resources/features/Karalljo.feature
# Generated by Cucable
...with <includeScenarioTags>@Regression</includeScenarioTags>
=> 1 feature was generated:
# language: en
Feature: Test
@Regression
Scenario: Check for Top Practice Areas and Jursidiction for an Expert Witness
Given a new request is created for the "test" user and "profilesuite" user
And the "Accept" header is set to "application/atom+xml"
And the path parameter "entityId" is "1234"
When the "GET" request is called for "PROFILE_S"
Then the response code is "200"
And the response body contains following text:
|Case Experience by Area of Law|
# Source feature: src/test/resources/features/Karalljo.feature
# Generated by Cucable
...with <includeScenarioTags>@Regression</includeScenarioTags>
=> 1 feature was generated:
# language: en
Feature: Test
@v1-s-1234
@sprint-2
@rx.x
Scenario: Check for Top Practice Areas and Jursidiction for an Expert Witness
Given a new request is created for the "test" user and "profilesuite" user
And the "Accept" header is set to "application/atom+xml"
And the path parameter "entityId" is "1234"
When the "GET" request is called for "PROFILE_S"
Then the response code is "200"
And the response body contains following text:
|Case Experience by Jurisdiction|
# Source feature: src/test/resources/features/Karalljo.feature
# Generated by Cucable
So I did not see any error. Can you maybe provide more details?
Best,
Benjamin
Hi Benjamin,
Thanks for the quick response.
I couldn't able to test this with latest Version 1.4.0 due to the bug that i have posted in the separate thread. This issue can be reproducible With the version 1.1.0.
Please find the below screenshots:
Hey Benjamin,
I saw similar issue from list Support for tags above Examples #84 and as per the conversation this issue was resolved with the version 1.3.0.
Sorry for the redundant question.
Thanks for your time
Srinivas