IMO, while this is a convenience for the programmer, it should not be an excuse to write (what I take to be) worse tests. Of the many downsides of basing tests around concrete string representations, the one I’ve had to slog thru most recently is that it makes cross-platform testing a real pain and can require all sorts of tedious and brittle workarounds to deal with path, encoding, and line ending normalization.
My rule of thumb is: don’t test raw string input/output unless what you are trying to tests it the parsing and generation of concrete string representations. Otherwise, I think you are inviting a lot of fragility and violating the proper abstraction boundaries of the code under test.
Testing CLI’s via dune’s cram testing is a special case here, in my view: if you are testing a CLI, you are necessarily testing the concrete string I/O.
Based on the name of this test, parsing a minimal pod, I would think that what we mainly want to focus on here is testing that we can read parse a string into the expected program. So I would probably inclined to do nothing with JSON here at all: rather, I would just want some tests that parsed into values of the program type and then compared that against my expected value of the time.
I would want a separate set of tests to check that, given a pre-determined program, I can generate the expected Yojson. This may actually be a nice place to employ property based testing.
I would only use expect tests for testing CLI interaction and/or pretty printing of my custom data (e.g., if you have a concrete representation of programs).
Nice looking project, thanks for sharing! The bits of code I looked over seem quite clean too 
Looking forwarding to seeing how it evolves