I'm submitting a ...
What is the current behavior?
Currently, any exception occurred in a step definition makes the step and the test failed (indicated with red in the report) regardless of whether it is a failed assertion or an unexpected error.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
-
Given the feature definition:
Feature: Feature with a failed step
Scenario: Scenario with a failed step
Given the step throws an unexpected error
-
And the step definition:
[Binding]
public static class StepDefinitions
{
[Given("the step throws an unexpected error")]
public static void ThrowError()
{
throw new Exception("An unexpected error");
}
}
-
The test result is rendered like this:
What is the expected behavior?
The test and the step should have the broken status (indicated with yellow).
What is the motivation / use case for changing the behavior?
This is a distinction that is expected by users based on their experience with other integrations.
Please tell us about your environment:
Other information
This can be tricky to implement due to SpecFlow having multiple runners. We don't know in advance which one the user chooses. The following strategies might be considered:
- Try guess the assertion exceptions of the most popular runners (xUnit.net, NUnit).
- Provide a user with the configuration similar to how allure-nunit handles it.
I'm submitting a ...
What is the current behavior?
Currently, any exception occurred in a step definition makes the step and the test failed (indicated with red in the report) regardless of whether it is a failed assertion or an unexpected error.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
Given the feature definition:
And the step definition:
The test result is rendered like this:
What is the expected behavior?
The test and the step should have the
brokenstatus (indicated with yellow).What is the motivation / use case for changing the behavior?
This is a distinction that is expected by users based on their experience with other integrations.
Please tell us about your environment:
Other information
This can be tricky to implement due to SpecFlow having multiple runners. We don't know in advance which one the user chooses. The following strategies might be considered: