Writing portable tests using random data John Cowan (04 Jun 2026 06:59 UTC)
Re: Writing portable tests using random data Peter McGoron (04 Jun 2026 12:53 UTC)
Re: Writing portable tests using random data Wolfgang Corcoran-Mathe (04 Jun 2026 19:46 UTC)

Re: Writing portable tests using random data Wolfgang Corcoran-Mathe 04 Jun 2026 19:46 UTC

John,

On 2026-06-04 02:59 -0400, John Cowan wrote:
> Suppose my tests depend on having determinized random data as input so that
> I can validate the output against golden data that ships with the tests.
> How can I initialize the random port in a portable way?
>
> If I use (srfi 271 determinized), the random data generated on your Scheme
> may be different from the random data I used to create the golden data and
> the tests will fail. But if I use a specific determinized library, it may
> not be available on your system.

This seems like another one of those wrenches designed specifically
to slip between the cogs of SRFI 271 and cause mayhem.

At the risk of falling into the rightly-loathed "don't do that, then"
mode, I'd say this is a bad way to test.  Test properties, not whether
a known pseudorandom sequence gives you hardcoded data.

But let's assume you really have to do this.  (And maybe you do--what
do I know?)

Shipping your own determinized library with the tests moves you down one
level in an infinite regress.  How do you portably define a new random
port type?  Currently you don't, since this SRFI specifically avoids
Scheme-level type definitions.  So you will need to
write--or, better yet, clone from some well-known repository--a suite of
implementations of your specific library.  This is clumsy, but workable.

The other alternative, as you suggest, would be to use a standard
determinized library with a very specific state format and
initialization protocol.  But adding a specification for such a
library to SRFI 271 would involve a fair amount of low-level detail,
which I think the SRFI has so far avoided.

My preference is for the first option.  Clumsy it may be, but then,
so is the use-case itself.  (Or so it seems to me.)

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>