Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Trace #17

Closed
j-hui opened this issue Jun 16, 2021 · 1 comment
Closed

Improve Trace #17

j-hui opened this issue Jun 16, 2021 · 1 comment
Labels
not-urgent Use this labels for issues that are not urgent.

Comments

@j-hui
Copy link
Collaborator

j-hui commented Jun 16, 2021

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 j-hui added the not-urgent Use this labels for issues that are not urgent. label Jun 21, 2021
@j-hui
Copy link
Collaborator Author

j-hui commented Aug 5, 2021

Closed in #46

@j-hui j-hui closed this as completed Aug 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not-urgent Use this labels for issues that are not urgent.
Projects
None yet
Development

No branches or pull requests

1 participant