Generation of test case data for Scala and Java, in the spirit of QuickCheck. When your test fails, it gives you a minimised failing test case and a way of reproducing the failure immediately.
The existing API for inlined test case rejection, using Trials.whenever works, but forces the user to adopt a pattern of examining the test case input(s) up front in a predicate, then proceeding with the rest of the test within a Runnable lambda (Java) or a lazily-evaluated code block (Scala).
This is fine as long as the decision to accept or reject the test case can be made up front, but sometimes we need to reject in the middle of running the test - this is especially relevant when testing stateful systems using an executable test plan. By the time a test plan is executing, the test is well and truly stuck in the nitty-gritty of driving the stateful system; a decision to reject the test case will be made on behaviour of the stateful system as it responds to an update.
What is needed here is an additional Trials.reject method that rejects the implied current test case, aborting the trial - this is what Trials.whenever does when its precondition fails. Using Trials.reject affords the user more flexibility - it can be called deep in the test's logic, possibly as part of a try-catch construct, or controlled by an if construct.
The implementation already exists under the hood for this; perhaps it is worth cutting over existing tests for Trials.whenever to use Trials.reject and mark the former as deprecated...
The existing API for inlined test case rejection, using
Trials.whenever
works, but forces the user to adopt a pattern of examining the test case input(s) up front in a predicate, then proceeding with the rest of the test within aRunnable
lambda (Java) or a lazily-evaluated code block (Scala).This is fine as long as the decision to accept or reject the test case can be made up front, but sometimes we need to reject in the middle of running the test - this is especially relevant when testing stateful systems using an executable test plan. By the time a test plan is executing, the test is well and truly stuck in the nitty-gritty of driving the stateful system; a decision to reject the test case will be made on behaviour of the stateful system as it responds to an update.
What is needed here is an additional
Trials.reject
method that rejects the implied current test case, aborting the trial - this is whatTrials.whenever
does when its precondition fails. UsingTrials.reject
affords the user more flexibility - it can be called deep in the test's logic, possibly as part of a try-catch construct, or controlled by an if construct.The implementation already exists under the hood for this; perhaps it is worth cutting over existing tests for
Trials.whenever
to useTrials.reject
and mark the former as deprecated...