Test the full CKEditor editing lifecycle.

[ChristopherChudzicki]

Our NodeJS testing environment can't run CKEditor because it relies on browser APIs like contenteditable. We should have some integration/e2e testing of CKEditor to give us more confidence that our code continues to work when we (a) add more features / changes, or (b) upgrade Ckeditor.

If we had a testing environment that could run CKEditor, we could:

• test the full data transformation process (see below)
• test plugin UI
• have more confidence when we upgrade major versions of CKeditor.

Original post

We store page data as markdown, but CKEditor, our WYSIWYG editor, is intended for WYSIWYG editing of HTML. So we play a bit of a "telephone game" during editing:

  graph LR;
    MD[Markdown];
    CK[CK Editor Model];
    HTML["Data HTML <br> (author never<br>sees this)"];
    EHTML["Editing HTML <br> (what the<br>author sees)"];
    MD-- "1. ✅" -->HTML;
    HTML-- "2. ⚠️ <br>('data upcast')" -->CK;
    CK-- "3a. <br> update with <br> each edit" -->CK;
    CK-- "3b. <br> update with <br> each edit" -->EHTML;
    CK-- "4. ⚠️ <br>('data downcast')" -->HTML
    HTML-- "5. ✅" -->MD;

Loading

1. Convert markdown to HTML
2. Feed the HTML to CKEditor
3. Make some edits in CKEditor...The internal model + display ("Editing HTML") are continually updated. Then click "save"...
4. Convert CKEditor internal rep to HTML
5. Convert HTML to Markdown

✅: We currently have thorough testing of steps 1 and 5: We check that we can losslessly convert markdown to-and-from HTML.

⚠️ However, we do not have any coverage of steps 2 and 4. Testing these steps is our responsibility, at least where our editor plugins are concerned, e.g., resource links and resource embeds.

In other words, we currently test f₅((f₁(markdown)) === markdown.

To-do

I think we'd get better reliability from testing f₅(f₄(f₂(f₁(markdown)))) === markdown