andygrove opened a new issue, #2020: URL: https://github.com/apache/datafusion-comet/issues/2020
### What is the problem the feature request solves? We currently rely on end-to-end integration tests to ensure that expressions are serialized correctly. This has generally been ok, but we have had issues such as https://github.com/apache/datafusion-comet/issues/1260 where we did not serialize all the fields for an expression, resulting in correctness issues. Now that we are refactoring the serde logic to encapsulate expression serde logic in their own classes as part of https://github.com/apache/datafusion-comet/issues/2019, it would be possible to start to write unit tests. Here is one example: ```scala test("add") { val add = Add(Literal(1), Literal(2), EvalMode.ANSI) val proto = CometAdd.convert(add, Seq.empty, binding = true) val expected = """add { | left { | literal { | int_val: 1 | datatype { | type_id: INT32 | } | } | } | right { | literal { | int_val: 2 | datatype { | type_id: INT32 | } | } | } | fail_on_error: true | return_type { | type_id: INT32 | } |} |""".stripMargin assert(proto.get.toString == expected) } ``` Another approach may be to generate "golden" files in the repo, similar to how we test for expected plans. Let's use this issue to discuss whether we should start adding unit tests for serde logic, and what form they should take. ### Describe the potential solution _No response_ ### Additional context _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org For additional commands, e-mail: github-h...@datafusion.apache.org
