search

sageserpent-open / americium

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.
MIT License
15 stars 1 forks source link

Simplified inline test case rejection. #58

Closed sageserpent-open closed 1 year ago

sageserpent-open commented 1 year ago

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...

sageserpent-open commented 1 year ago

This went out in release 1.10.2, Git commit SHA: 28042dbe9cf7ac3ceb9bda14e6bed26a32c0bdb1 .

Trials.whenever has not been deprecated as it is reads better in some situations.