-
Notifications
You must be signed in to change notification settings - Fork 20
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
[WIP] Unit tests #126
base: master
Are you sure you want to change the base?
[WIP] Unit tests #126
Conversation
There is much divergent and poorly-documented on display here
As suggested by gRegor and Tantek Çelik, this avoids any implication we are testing real vocabularies, past, present, or future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spot checked all the files and what I checked looked good. Lots here and at this point I think we should land this and see how existing parser implementations do, and then investigate any failures in detail to verify that any failing test is itself valid.
I have no objections to merging the work thus far as a partial test suite, though I should probably write up some draft documentation (more or less what's detailed in the cover of this request) first. Is there a preferred format? Plain text, markdown, HTML, something else? |
Personally I think a markdown file containing basically what is in the PR description would be nice. Linked to from README, I would say, and maybe even at the root level of the repository. But there does not seem to be any precedent. There are some changelog files, but honestly I have never read them, in part because they are HTML files. That makes it basically a requirement to clone the repo and open it with a browser to read comfortably. That is why I would prefer markdown, GitHub has native support for it, and it will be easier to refer to it inside the repo. |
I've been using https://keepachangelog.com/ format recently on some projects and liking it. |
This patch constitutes a series of generic unit tests for microformat parsers, using the existing test format. While it is not possible to segregate certain parsing features entirely (notably implied property parsing), I've attempted to keep to the following design philosophy:
example.test
is used instead ofexample.com
, as the former is guaranteed never to be a real domaintentative-
so that they may be easily skipped; these files reflect common behaviour among established implementations where there is majority agreementAt present the test suite offers only partial coverage. The to-do list is thus:
textContent
parsinglang
parsingtextContent
parsingsrcset
parsingI am posting this while still far from finished to gather feedback early. I expect it will take me quite a while to do everything, but what's here can already be useful to implementers.