WIP: Add JSON serialization and additional frame testing utilities #2920
+331
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm working on adding some custom FrameProcessor testing capability to the pipecat CLI. This PR adds a few things to help with that.
The goal is to be able to define input frames and optional expected output frames in JSON, like this:
{ "input_frames": [ {"type": "TextFrame", "text": "hello world"}, {"type": "TextFrame", "text": "testing 123"} ], "expected_output": [ {"type": "TextFrame", "text": "HELLO WORLD"}, {"type": "TextFrame", "text": "TESTING 123"} ] }The existing run_test function requires you to define expected output frames and has test assertions built in. This PR effectively re-implements run test as
run_test_from_fileto move the assertions part to a separate function. This lets us make expected_output optional, so we can run the FrameProcessor without knowing what output we expect when we're building our FrameProcessor.The custom validator also adds a bit more utility, such as validating field contents instead of just frame types. It also starts to build out a bit of a testing DSL, like adding
_containsto a string field to test for contains instead of equals, like:{"type": "TextFrame", "text_contains": "TESTING"}from the example above.There's some mild duplication in creating a separate
run_test_from_filefunction. It's just extremely simple pipeline creation, and I think it's worth it not to disturb the existingrun_testfunction. But I could be convinced otherwise.