The PR changes the TCK API so that it adds the @NegativeTest tag to all scenarios that have an ExpectedError step, which is precisely the meaning of the tag. As a result, the tag has not to be provided manually in feature files anymore, but appears automatically when scenarios are parser through the API. If a scenario still has the tag in the feature file, the TCK API does not add the tag.
The PR removes the @NegativeTest tag from scenarios in exiting feature files.
The PR removes a check in the ScenarioFormatChecker, that checked that scenarios have either both, an ExpectedError step and @NegativeTest tag, or neither of the two. Since, the TCP API takes care of the tag this check is superfluous, now.
It can be argued that, with this PR, the ScenarioFormatChecker should check that the scenarios in the feature files do not contain the @NegativeTest tag. However, that is not straightforward since the ScenarioFormatChecker consumes the scenarios through the TCK API, too. It is certainly imaginable to let the ScenarioFormatChecker know if a tag was added by the TCK API or allow switching off tag inference. However, that seems unnecessarily complicated and not worth the cost at this point. Such things can still be added later, probably when more tag inferencing is added to the TCP API or as a separate tool.
The purpose of the @NegativeTest tag is to ease finding and filtering negative test scenarios.
This PR builds on #487
The PR changes the TCK API so that it adds the
@NegativeTesttag to all scenarios that have anExpectedErrorstep, which is precisely the meaning of the tag. As a result, the tag has not to be provided manually in feature files anymore, but appears automatically when scenarios are parser through the API. If a scenario still has the tag in the feature file, the TCK API does not add the tag.The PR removes the
@NegativeTesttag from scenarios in exiting feature files.The PR removes a check in the
ScenarioFormatChecker, that checked that scenarios have either both, anExpectedErrorstep and@NegativeTesttag, or neither of the two. Since, the TCP API takes care of the tag this check is superfluous, now.It can be argued that, with this PR, the
ScenarioFormatCheckershould check that the scenarios in the feature files do not contain the@NegativeTesttag. However, that is not straightforward since theScenarioFormatCheckerconsumes the scenarios through the TCK API, too. It is certainly imaginable to let theScenarioFormatCheckerknow if a tag was added by the TCK API or allow switching off tag inference. However, that seems unnecessarily complicated and not worth the cost at this point. Such things can still be added later, probably when more tag inferencing is added to the TCP API or as a separate tool.The purpose of the
@NegativeTesttag is to ease finding and filtering negative test scenarios.