You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 ofOutput
looks like. We currently use a parser to convert from the latter to the former, and don't have any mechanism for dumping anOutputEntry
to what a line should look like in the running C program. There are two ways to fix this: (1) overload theShow
instance forOutputEntry
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 theShow
instance looks like. I'm personally in favor of the latter since it means we can justread
instead of using a separate parser.Right now, the semantic equality comparison procedure lives in a
PropertyM
monad 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
, whereNothing
indicates equality andJust d
indicates inequality withd
containing all the information thePropertyM
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.The text was updated successfully, but these errors were encountered: