v2.4.10 TestCase disposition

What's Changed

• Test updates by @Kritner in #17
• Adds overall test case disposition, additional tests by @Kritner in #19
  • Mostly done to make some meaningful test asserts but whatevs 😅

Full Changelog: v2.3.13...v2.4.10

v2.3.13 - Documentation/Test update

What's Changed

• Adds tests for #11 that should have been added in #12 by @Kritner in #13
• Coveralls by @Kritner in #14
• Fixing a copy/paste issue with XML documentation around the `MaybeFix… by @Kritner in #15

Full Changelog: v2.2.5...v2.3.13

v2.2.5 - Bug fix on `MaybeFixedTheory`

What's Changed

• Fixes MaybeFixedTheory by @Kritner in #12
  • Was building up a FlakyTestCase in the MaybeFixedTheory discoverer rather than MaybeFixedTestCase

Full Changelog: v2.1.5...v2.2.5

v2.1.5 - Downgrade XUnit dependency

What's Changed

• Downgrading the XUnit version being used in the src project by @Kritner in #10

Full Changelog: v2.0.4...v2.1.5

v2.0.4 - [MaybeFixed] attributes

What's Changed

Adds [MaybeFixedFact] and [MaybeFixedTheory] attributes for use in helping to confirm a recently refactored batch of code and/or tests result in a no longer flaky test

PRs

• Feature/7 check no longer flaky by @Kritner in #8
• "Skip" attribute testing, fix bug in MaybeFixedTheoryDiscoverer by @Kritner in #9

Full Changelog: v1.0.5...v2.0.4

v1.0.5 - the first one

FlakyTest.XUnit

Do you have some flaky tests? Are you using XUnit? Do you want to retry your flaky tests a few times before considering them failures? Heck yeah brother! (You should probably actually fix the test so it's not flaky, but sometimes you just don't have time!)

If you still want an easy way to mark a test or two (but no more than that!) as flaky, then this might be the package for you.

Usage

It probably can't get much easier to consume this functionality. If you're already used to decorating your test methods with [Fact] you're almost there!

using FlakyTest.XUnit.Attributes;

[FlakyFact("this test is heckin flaky my dude, follow up to fix this in JIRA-1234", 42)]
public async Task WhenDoingThing_ShouldHaveThisResult()
{
   // your test implementation which is sometimes flaky
}

The project requires the first string parameter flakyExplanation to be not null/empty... cuz you really shouldn't be using this anyway. This can be used as a way to describe how/why the test is flaky, and perhaps leave a note and ticket for follow up to get the flakyness aspect of the test fixed.

The second parameter indicates how many times the test can "fail" before the test runner actually reports it as failure. The default value here (at the time of writing this) is 5 - meaning the test can fail 5 times prior to the runner reporting it as a failure. If the test passes on the first, fourth, or any test in between, it is immediately marked as successful to the runner.