Provide RandomSource in PropertyContext
See original GitHub issueFor certain tests it might be useful to have access to a deterministic random source. For example when working on (large) lists with expensive computations, where it is too expensive to verify all combinations exhaustively. Or simply when one element or a subset must be selected.
It would be helpful to be able to simply call:
val element = theCompleteList.random(random)
Omitting the random argument results in a test that is not repeatable.
Since the properties execute in the context of PropertyContext, it would be possible to proved the randomSource as a public member.
Issue Analytics
- State:
- Created a year ago
- Comments:13 (12 by maintainers)
Top Results From Across the Web
Pomcor JavaScript Cryptographic Library (PJCL)
provide 128 and 196 bits of security strength respectively [9, Table 2], ... bits with sufficient entropy obtained from a true random source....
Read more >The SELinux Notebook - lesstif.com
A framework that provides hooks into kernel components ... but the client will be assigned a random source port. The CONNSECMARK will ensure ......
Read more >The SELinux Notebook - The Foundations - Free Tech Books
to provide Mandatory Access Control services for GNU / Linux. Hopefully it will ... but the client will be assigned a random source...
Read more >The SELinux Notebook - Agenda INFN
A framework that provides hooks into kernel components ... but the client will be assigned a random source port. The CONNSECMARK will ensure ......
Read more >Web Gateway 7.6.2 Product Guide - Knowledge Center
Providing SSO services for SAML 2.0 cloud applications . ... When this option is not selected, the appliance chooses a random source port...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Sorry to complicate this further. I’ve just created https://github.com/kotest/kotest/issues/3076, suggesting the possibility to run the shrunk case, by skipping over the large iterations.
This new feature requires that the random source is completely controlled by the kotest framework, and no interactions with it are outside the framework. This should be taken into account when solving this issue (https://github.com/kotest/kotest/issues/3046).
Instead of providing the actual random source from the framework, my suggestion is to create a new Random, seeding it it from the frameworks random source, and injecting the new Random into the test context. This way the RandomSource of the framework remains isolated from the Random provided to the test.
So in other words, using the provided random source wouldn’t move the framework’s random source on? So we’d create a “seed” random from the seed value, and then use that to generate a random per test, which would be fed into the test for users to use?
Something like
val seedRandom = Random(seed) for (iteration in iterations) { val testRandom = Random(seedRandom.nextLong()) }