Include unit tests for default plugins

[tlylt]

What is the purpose of this pull request?

• Documentation update
• Bug fix
• Feature addition or enhancement
• Code maintenance
• Others, please explain:

Overview of changes:
This PR partially addresses #781. I have included unit tests for default plugins as a means to complement existing functional tests.

Anything you'd like to highlight / discuss:
In the unit test for markbind-plugin-plantuml, I decided to mock fs and child_process modules such that generateDiagram will not actually launch plantuml.jar to convert plantuml code into an image file. This is because that process seems to be covered in functional tests as plantuml diagrams will be generated in the expected/diagrams folder. I did not unit test the generateDiagram function because it is not an exported function. I am not sure if that is a good reason but I am thinking since it is somewhat private and inaccessible to other modules, perhaps I should not test it.

Testing instructions:
Run npm run test to verify that all tests are still passing. To only run the 3 added tests, cd into packages/core/test/unit/plugins/default and run
npx jest anchor.test.js, or
npx jest plantuml.test.js, or
npx jest shorthandSyntax.test.js

Proposed commit message: (wrap lines at 72 characters)
Include unit tests for default plugins

There are severe plugins that have specific functionalities
but are not unit tested.

Some of the edge cases might be harder to test with functional tests.

Let's add unit tests for default plugins to verify their functionalities.
For example, processNode should correctly modify the
node passing in according to a plugin's purpose.

---

Checklist: ☑️

• Updated the documentation for feature additions and enhancements
• Added tests for bug fixes or features
• Linked all related issues
• No blatantly unrelated changes

[wxwxwxwx9]

Hi @tlylt! Good job on this PR :-) I've looked through your changes and left some comments for discussion/changes.

The tests for PlantUML looks good to me, I think the control flows for the function is well-tested. Don't think there is anything we missed out.

For the other 2 tests, I have written some minor comments.

Thanks for your contribution!

[wxwxwxwx9]

While reviewing your PR, I went to look at some of our code for the anchor plugin and it got me thinking whether we refactor our anchor plugin. Specifically for this <span> anchor node, we are currently adding it in processNode file instead of adding it in our anchor plugin processNode function.

But it seems to me like this <span> anchor node is pretty "coupled" with the anchor plugin, since our anchor plugin wouldn't work without this <span> anchor node. Thus, I was thinking it may be better if we shift that portion into our anchor plugin file?

It would also make more sense for this test case to include that <span> node, in my opinion. As it stands, even if we remove this <span> node, we are still testing the functionality of our anchor plugin function fine.

But I may be missing some context @ang-zeyu do you know anything about this? :O

@tlylt feel free to chip in as well!

[wxwxwxwx9]

I think it would be good to add short inline comments to explain how are these syntaxes improper, so readers don't have to refer to the function to infer what the proper syntax should be. It also serves as also a form of verification of what improper syntax we are actually testing.

[tlylt]

Hi, thanks for the comment. I have adjusted the test cases for the shorthandSyntax plugin and included in a comment at the top to show the desired outcome. Hope that's clearer.

[wxwxwxwx9]

I think maybe this can be included in the "improper syntax nodes" as well, but it's fine if we leave it here also. I leave it up to you :-)

[tlylt]

I decided to split the improper syntax test case into two so that it's clearer as to why it's improper. So I will keep this one separate as well. Thank you for the suggestion.