Modularize functional (snapshot) tests, for plugins where possible.

[gerteck]

Please confirm that you have searched existing issues in the repo

Yes, I have searched the existing issues

Any related issues?

#1637

What is the area that this feature belongs to?

No response

Is your feature request related to a problem? Please describe.

I think there is some refactoring that could help optimize our testing for developer experience and future maintenance efforts.

Currently, the "test jumbotron" has 57 pages testing a variety of components.

In particular,

https://github.com/MarkBind/markbind/blob/8c9de42d78a67e4e73d8ed06c39d741ed71ddeb2/packages/cli/test/functional/test_site/site.json#L229-L258

Test jumbotron also does tests for most of the plugins.

Why is this an issue? Most of the plugins append some js script to the html of a page. This means that any updates to the plugin script (comment, typo etc) would mean that an update to numerous snapshot test files ( in particular - more than 57 pages).

This is demonstrated in PR #2614 - a change in mermaid script indirectly causes 4k+ LoC changes, much of which is due to adding duplicated script content to irrelevant pages.

The same issue could occur if we update other plugins - web3Form, googleAnalytics etc. Let'a adopt an approach as in dataTables plugin - create a new (minimal) site to do functional tests per plugins, i.e. modularize the test sites. This is so we can keep the scope of changes limited and give any PR reviewer a much easier time as well.

This is highly related to #1637 (test site improvements). I want to highlight that the ignoring of the render function file in this issue is also very relevant and can be tackled in a similar PR. - Although it is not hard to do so, it would be quite beneficial.

I hope this issue can provide some context as to why refactoring of the test files would be good.

Describe the solution you'd like

Refactoring of tests

Describe alternatives you've considered

No response

Additional context

No response

[tlylt]

Let'a adopt an approach as in dataTables plugin - create a new (minimal) site to do functional tests per plugins, i.e. modularize the test sites. This is so we can keep the scope of changes limited and give any PR reviewer a much easier time as well.

There are reasons why we don't simply create a new test site:

• when breaking changes are introduced, we need to migrate the test sites that might be outdated.
• test performance

Probably other reasons discussed in older issues, but the above jumped to my mind