-
-
Notifications
You must be signed in to change notification settings - Fork 59
An idea for tests #174
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
Comments
Heya @johnlepikhin 👋 markdown-rs/fuzz/fuzz_targets/markdown_libfuzz.rs Lines 1 to 12 in dcf8a63
This is not true. As an example, these are both strong text **Bold** __Bold__ when run through markdown-rs you will get strong text back on the other side, but you are not guaranteed to get the same marker characters that were originally used, those were abstracted.
round trip testing is another useful approach, this is already done on the JavaScript implementation, |
As a consequence of issue #169, I just wanted to suggest a technique of testing parsers and printers. Parsing and printing (serializers and deserializers) are mutually inverse functions: the result of
print(parse(some_text))
should besome_text
itself – in case ifsome_text
is well-formatted. Thus, it is really easy to write parser+printer tests literally in declarative style:The text was updated successfully, but these errors were encountered: