Switch to xUnit.net 2.0 #51
Comments
#51 refactor: added v2 acceptance tests, minimal v2 impl
|
I checked xBehave.Core. Looks good. |
|
Great, thanks for trying it! With regard to the crazy idea, unfortunately xunit does not have the concept of an inconclusive test result. The only possible results are Failed, Passed and Skipped. What we could do is have new version of [assembly: ContinueOnFailureAfter("^Then")] |
|
That would work for me. |
|
OK, let's get that into RC3. |
|
I migrated a lot of specs to xBehave 2.0. All works well, no problems found. Hope you get rid of the pre-release soon - so that my automatic scripts for updates work again :-) |
|
That's great! It certainly gives the RC a good vote of confidence. |
|
@ursenzler I've spent some good time agonising over the 'continue on failure' feature. What bothered me was that it's a highly specific extension and, especially, one that I've never used. So I came up with a different idea. I've added a new step builder method, [Scenario]
public void Something()
{
"Given something"
.f(() => ...);
"When something"
.f(() => ...);
"Then something"
.f(() => ...)
.ContinueOnFailure();
"And something else"
.f(() => ...);
"And something else again"
.f(() => ...);
}In this scenario, if This allows control of the behaviour at the most granular level possible, i.e. individual steps. This is a feature I think I might use 😉. Now, in order to allow people to emulate the behaviour of the 1.x [Scenario]
[ContinueOnFailureAfterThen]
public void Something()
{
"Given something"
.f(() => ...);
"When something"
.f(() => ...);
"Then something"
.f(() => ...);
"And something else"
.f(() => ...);
"And something else again"
.f(() => ...);
}
// your own custom extension
public class ContinueOnFailureAfterThenAttribute : StepDefinitionsFilterAttribute
{
public override void Filter(ICollection<IStepDefinition> steps)
{
foreach(var step in steps.SkipWhile(step => !step.Text.StartsWith("Then ")))
{
step.ContinueOnFailure = true;
}
}
}Implementations of 2.x Thoughts? |
|
I like the idea with the attribute more. Mainly because I use "establish", "when", "it", "it" with no distinction between the assertion steps. The step builder method brings the concept of order to my assertion steps, which I don't like. What if I change the order? The attribute would allow to run all "it" even if a single "it" fails. That's what I like. |
|
Which attribute are you referring to? There is the old 1.x attribute and the proposed new 2.x attribute. |
|
With 2.x attribute you can achieve what you want like so: [Scenario]
[ContinueOnFailureAfterIt]
public void Something()
{
"Establish something"
.f(() => ...);
"When something"
.f(() => ...);
"It something"
.f(() => ...);
"It something else"
.f(() => ...);
"It something else again"
.f(() => ...);
}
// your own custom extension
public class ContinueOnFailureAfterItAttribute: StepDefinitionsFilterAttribute
{
public override void Filter(ICollection<IStepDefinition> steps)
{
foreach(var step in steps.SkipWhile(step => !step.Text.StartsWith("It ")))
{
step.ContinueOnFailure = true;
}
}
}You don't need to use the step builder method at all. And you can freely change the order of your |
|
I meant that the new proposed attribute solution is just perfect for my needs. |
|
Ah, great! 😄 OK, so that will be part of RC3 - tracked by #254 |
This is an opinionated subset of 1.0 features which I believe are required in version 2. If any features have been omitted, it is because I have never used them, nor have I heard of anybody using them, or I have only heard of them being used in an edge case. Ultimately the framework is designed to be extensible so if any edge cases are not being catered for then the extensibility points should be examined first before adding specific features.
This issue only tackles net45 support. Support for other platforms has been spun off into #220, #221, #222, #223 and #224.
ITestCaseCleanupFailureif required (2.0 change)ITestCaseCleanupFailureif requiredThe text was updated successfully, but these errors were encountered: