Testing approach concept

[joshbruce]

Marked version: 0.3.17

Description

http://spec.commonmark.org/0.28/#example-12

Been thinking about priorities and testing, given the analysis of our current test bed. Further, there are a lot of issues that are more spec-related that may or may not include the Markdown and expected HTML output...

Anyway, long story short and we can expound in the comments.

Thinking we should possibly stick to our guns (or appear to adjust the) priorities.

We don't have any known security issues.

We know we have a lot of issues submitted by users. Most of those seem related to not being compliant with the spec, which is a higher priority than user-specific things.

We also have the base for creating the simplest complete spec-compliant test bed ever...even someone who has no idea how marked works could do this.

1. Go to the tests.
2. Look for a flavor and example (cm_example_12, in this case).
3. If it's there, that gives users confirmation and trust that we have that covered.
4. If it's not there:

• Create an md and HTML file in /new (would be really nice to be able to put tests in a folder named after the flavor /commonmark, for example).
• Literally copy and paste.
• Run npm test

5. Submit the PR.

Or, if it's broken and you know how to fix it, fix it. Otherwise, we have the PR available for someone else to come in and pick it up.

I think if we can confirm spec compliance with the testing harness we have, might be easier for us to close them out.

Maybe we can get random people to help out...none of us need to know how marked works to do this.

Contributor

• Test(s) exist to ensure functionality and minimize regresstion (if no tests added, list tests covering this PR); or,
• no tests required for this PR.
• If submitting new feature, it has been documented in the appropriate places.

Committer

In most cases, this should be a different person than the contributor.

• Draft GitHub release notes have been updated.
• CI is green (no forced merge required).
• Merge PR

[UziTech]

I like the idea of having tests sorted by spec. That will make keeping up with spec changes very easy.

[joshbruce]

Tagging @intcreator

[joshbruce]

I'm starting to reconsider the idea of fixing. Would like to try and get a message out to users of what the strategy is before we actually start making more changes to the code itself.

[intcreator]

I like the idea of tests being per-spec. I also agree that we should prioritize spec compliance before individual user requests.

[davisjam]

I like the idea of tests being per-spec. I also agree that we should prioritize spec compliance before individual user requests.

+1. Spec compliance should be a higher priority.
This may capture some user requests along the way, and will help us identify any user requests that conflict with the spec.

[joshbruce]

All right. Preparing a game to try and recruit some help on that project while possibly getting some more feedback on market viability and demand. Let's leave this one open for a minute...I'll be the one to merge. (Also, fair warning, this might be one of those, "Josh is doing a bunch of stuff" kinda days.)

[UziTech]

Thanks for the warning 👍

[joshbruce]

See #1159