If we want to fiddle with the event trace for coarser grained testing (e.g., only containing externally-visible events to accommodate optimizations), we might want to tidy up its definition and clarify its interface/the behavior it entails about a running program.
There are a few things I had in mind:
Right now, we are juggling between two different String representations of traces, i.e., what the C program prints out, and what the Show instance of Output looks like. We currently use a parser to convert from the latter to the former, and don't have any mechanism for dumping an OutputEntry to what a line should look like in the running C program. There are two ways to fix this: (1) overload the Show instance for OutputEntry instead of deriving it, to essentially do the opposite of what the parser is doing; or (2) adjust what the C runtime is printing to match what the Show instance looks like. I'm personally in favor of the latter since it means we can just read instead of using a separate parser.
Right now, the semantic equality comparison procedure lives in a PropertyM monad in Test.Ssm.Output, with some ad hoc diff generation. It should live outside of that monad, like it did before, but instead of just returning a Boolean indicating equality, it should return a Maybe Diff, where Nothing indicates equality and Just d indicates inequality with d containing all the information the PropertyM monad needs to report the information to the test driver.
There's a test input list still living in the Trace.hs file, which was used for testing. This should probably be placed somewhere else, perhaps in a separate test suite specific to checking basic things about the trace (e.g., the parser, if we still we still need it, as well as some higher level properties about what it means for two traces to be equal.
j-hui
commented
2 years ago
If we want to fiddle with the event trace for coarser grained testing (e.g., only containing externally-visible events to accommodate optimizations), we might want to tidy up its definition and clarify its interface/the behavior it entails about a running program.
There are a few things I had in mind:
Right now, we are juggling between two different String representations of traces, i.e., what the C program prints out, and what the
Showinstance ofOutputlooks like. We currently use a parser to convert from the latter to the former, and don't have any mechanism for dumping anOutputEntryto what a line should look like in the running C program. There are two ways to fix this: (1) overload theShowinstance forOutputEntryinstead of deriving it, to essentially do the opposite of what the parser is doing; or (2) adjust what the C runtime is printing to match what theShowinstance looks like. I'm personally in favor of the latter since it means we can justreadinstead of using a separate parser.Right now, the semantic equality comparison procedure lives in a
PropertyMmonad inTest.Ssm.Output, with some ad hoc diff generation. It should live outside of that monad, like it did before, but instead of just returning a Boolean indicating equality, it should return aMaybe Diff, whereNothingindicates equality andJust dindicates inequality withdcontaining all the information thePropertyMmonad needs to report the information to the test driver.There's a test input list still living in the
Trace.hsfile, which was used for testing. This should probably be placed somewhere else, perhaps in a separate test suite specific to checking basic things about the trace (e.g., the parser, if we still we still need it, as well as some higher level properties about what it means for two traces to be equal.