Generalize splits #76
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR generalizes the split testing functions in the typed-protocols library to allow testing real client decoder functions instead of just codec tests, improving code coverage of client libraries.
- Added
io-classesdependency forMonadSTsupport - Generalized split testing functions with additional parameters for channels and custom decoder functions
- Updated function signatures to support custom channel creation and decoder execution
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| typed-protocols.cabal | Added io-classes dependency for MonadST functionality |
| Network/TypedProtocol/Codec/Properties.hs | Generalized split testing functions with new parameters for channels and decoder functions |
| CHANGELOG.md | Documented the generalization of prop_codecF_splitsM function |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
typed-protocols/properties/Network/TypedProtocol/Codec/Properties.hs
Outdated
Show resolved
Hide resolved
To improve code coverage of client libraries, additional parameters were added to the function such that real client runDecoder functions can be tested in addition to the previous codec tests.
crocodile-dentist
force-pushed
the
mw/generalize-splits
branch
from
1116efe to
32e1671
Compare
| => (forall (st :: ps). annotator st -> f (SomeMessage st)) | ||
| -> (m (Maybe bytes) -> channel) | ||
| -> (forall (st :: ps). | ||
| channel | ||
| -> Maybe bytes | ||
| -> DecodeStep bytes failure m (f (SomeMessage st)) | ||
| -> m (Either failure (SomeMessage st))) |
There was a problem hiding this comment.
One problem is that we don't have a function which fits into this type in typed-protocols (running an incremental decoder against a channel), so it makes it a little bit awkward to have this type signature here.
There's no notion of channel in typed-protocols, that's why you had to have a polymorphic channel. I never fully agreed with it, but the point was that this part pulls some dependencies that are custom (e.g. contra-tracing, cborg).
With how things are right now, this fits more into some testing library in ouroboros-newtork. If we move various drivers and channels to some typed-protocols sublibrary, then this will fit here as well.
There was a problem hiding this comment.
I had similar thoughts about this and I think copying this test to o-n like you say makes more sense. We can leave this here as-is because the examples depend on it and it gives other users a starting point to making their own tests based on those.
There was a problem hiding this comment.
The typed-protocols:examples sublibrary does not depend on typed-protocols:codec-properties.
There was a problem hiding this comment.
The test depends on it, though, that's why there are a bunch of compilation errors.
Is it possible to implement the old API with the new one?
2 participants
To improve code coverage of client libraries, additional parameters
were added to the function such that real client runDecoder functions
can be tested in addition to the previous codec tests.