Think about a three-part "arrange, act, assert" approach to testing

[barrucadu]

Excerpt from an email:

However, this problem [adding a dontCheck function], and the problem I had which led to the
subconcurrency function, suggests to me that there's a better
abstraction for concurrency test cases than just a single concurrent
program. Normal testing has the "arrange, act, assert" and "given,
when, then" approaches and I bet a similar approach would work well
here. I'm pondering something like:

thisFunctionNeedsAName
    :: (MonadConc n, MonadRef r n)
    => Scheduler s
    -> MemType
    -> s
    -> ConcT r n a    -- "arrange": set up any state
    -> (a -> ConcT r n b)  -- "act": the action to test
    -> (a -> Either Failure b -> ConcT r n c)  -- "assert": check some
postcondition
    -> n (Either Failure c, s, Trace)

Where the "arrange" and "assert" components are run with some fixed
internal scheduler, don't show up in the trace, and don't count
towards bounds.

I think this idea has promise. Depending on what you can do in the "assert", perhaps it could remove the need for ProPredicate / Predicate entirely! That would be a rather big transformation.

I think the approach to take here is to change the internals to make that function possible (and SCT functions based on it), then to go look very carefully at other testing libraries, preferably ones which support nondeterminism in some way, for inspiration.

---

To provide arrange/act/assert-specific functionality we could do something like so:

data Mode = Arrange | Act | Assert

data ConcT (mode :: Mode) r n a = -- ...

someArrangeFunction :: ConcT 'Arrange r n Foo
someActFunction :: ConcT 'Act r n Bar
someAssertFunction :: ConcT 'Assert r n Baz

Concurrency functions would be polymorphic over the mode and so work in all of them.

This would probably be most useful for assert-specific functions to do things like signal test failure.