Crypto generators #382
Crypto generators #382
Conversation
| "chain-generators", | ||
| "chain-test-utils", |
There was a problem hiding this comment.
Should we try to keep all test utilities in a single crate? Or is chain-test-utils meant to be a core library onto which other generator crates with their varying dependencies are based? Trying to capture the intent here.
There was a problem hiding this comment.
What I had in mind was that in utils we should have whatever that deal with the chain libs testing part but that is common for them. What we have already, for example, the utilities for checking the serialization bijection. Also, I added the NonSecureRng in the utils because even if it is part of the generators stuff I think it is a general concept enough to be separated from the main ones. Also, some generators that I have in mind for the future (for example a generator that keeps track of the generated values to discard the duplicated ones) I was planning to put them here. By keeping them separated we may also import just the utils ones for implementing the same for some jormungandr types if we do not really need any chain type.
I don't say it is the best option though, and I see the value on keeping everything together (for example with a utils submodule inside the chain-generators crate).
What do @input-output-hk/jormungandr team think?
There was a problem hiding this comment.
I think it's OK to have a library of common test utilities and another providing the generator framework. Just keep these responsibilities clearly separated.
| @@ -0,0 +1,48 @@ | |||
| use chain_crypto; | |||
Use R::new instead of manually generating seed
|
Closing this for now. We are taking other dev paths for this. |
Created generators for:
Implemented utils generators:
Implemented insecure random number generator wrapper (just for testing).