Consistent rule references in tests #916
Conversation
|
Maybe I’m being wildly inconsistent here, but I like rule names in configuration files and comments for clarity, but I like rule numbers in test file “assertions” for conciseness. To me, the MD123 form is canonical for a rule and will never change. Whereas the name can change and has in a few cases. There will be only one MD123 per rule, but there can be multiple names. Which is all kind of an argument to use MD123 everywhere, BUT I appreciate clarity in configuration where there are often multiple rules being handled at once. My view on test files and preferring the {MD123} syntax there is that it should be short and unobtrusive and also because there is usually only one rule being tested in each file (with the file name and content making the scenario clear). Using the rule name in tests is more to type and easier to typo - while having both the number and number he name is redundant. So I’m keen on part of this change, but not all of it. Updating only the configuration sections will also make the diff much easier to review. |
There was a problem hiding this comment.
I like this change, thank you! It looks like there may be a merge conflict. And I may have added a new file or two in my last commits that should be included. I don't expect another commit on my part before merging this PR, so it should just be this one update. I hope you had some kind of automation to do/redo this vs. manually typing everything. :)
haha yeah. i'd proly lose my mind if i did this manually >.< i'll force push a rebase ommitting Always refer to rules by number:name in expectations and its revert commit. |
No tests on 'next' are broken by removing this
This is really in response to #845 (comment)
I think it makes sense to always refer to rules by human-readable name in test configs for clarity.
Referring to rules by number in expectations then makes less sense. The rules could always be referred to by name in expectations but ultimately there is some file
lib/md###.jsthat will be relevant when fixing a test. This is why I've gone withnumber:namefor expectations. This format has meant that in some instances lines are long enough to breakline-lengthrule.