Closed lucab closed 5 years ago
/cc @BusyJay @brson @overvenus for review.
Do Not Merge (DNM): I haven't tested this on any consumer yet. It would be good if somebody familiar with tikv
test-base could try to drop this one in place there and confirm I haven't missed/overlooked anything, before merging.
I'm not in a hurry to land this, I can wait till after 0.3 release (see https://github.com/pingcap/fail-rs/pull/37#issuecomment-501606095).
I updated tikv
testsuite to consume this: https://github.com/tikv/tikv/pull/4903. CI is green.
This is ready for review and fine to land before 0.3, if you like.
This is so cool! @brson would you like to take a look?
Seem like after this we should finally bump to 0.3, and integrate this pattern into tikv per @luca's patch.
The issue to bump to 0.3 is https://github.com/pingcap/fail-rs/issues/31. I know I don't have the permissions to tag and publish. So probably @BusyJay or @overvenus will need to do that.
@brson I've updated the docs to fix the example, and explained the reason for keeping cfg
as a free-function: https://github.com/pingcap/fail-rs/pull/40#discussion_r294685926.
@BusyJay after https://github.com/pingcap/fail-rs/pull/32, the appveyor configuration should be removed. It is still triggering (and failing) on PRs. I think it is under your account.
Gentle bump.
Thanks for this Luca! :)
Rebased on latest master to get rid of appveyor hanging status.
(EDIT: that seems to have dropped the two LGTMs too, sorry)
Thanks and sorry for the delay @lucab
@brson no prob. Actually, thanks for the reviews!
This adds a
FailScenario
to the library, exposing the usual idiom of a global testing mutex and individual guards owned by each test.The global mutex is kept as an internal detail and not exposed, consumers can only borrow a guard via the scenario.
Closes: https://github.com/pingcap/fail-rs/issues/23