Ckeditor5: Unit testing CKEditor 5 as a component in Vue

Created on 2 Apr 2018 · 4Comments · Source: ckeditor/ckeditor5

We are using CKEditor 5 with Vue.js and would like be able to test the component properly. Our current setup uses Vue Test Utils with Jest, which is pretty standard. Since some browser APIs that CKEditor 5 uses are not implemented in jsdom (a headless browser environment in JavaScript), it is not possible to mount the editor in unit tests right now. Do you have a suggested way of testing the editor?

discussion question

Source

ahmetsulek

All 4 comments

Generally speaking, if you want your test suite to be really useful, we don't recommend unit testing like this. We learnt many times that to ensure that things will really work we need to write more of integration tests than unit tests. The more you mock, the bigger the chance that your tests will work in an unrealistic environment.

In your case, the question is how sure you want to be that CKEditor 5 will work in your application and what you want to test.

If you want to test that it integrates well and that it will work in the browsers – then test in the browsers. Only this way you'll be sure that the integration will really work in all browsers. JSDom is incomplete and, what's more, it's just yet another DOM implementation. If the editor will ever work with it, you'll only be testing whether it works with it. But what about the browsers? Each of them has its own quirks and contentEditable's implementations are really full of them.

The other option is to focus only on the "engine" part of the editor. There's no official Headless editor yet, but it's fairly easy to do. Once you'd have it you would be able to load the part of each feature which requires only the engine to work (not the DOM). To enable that features are split into their *Editing and *UI parts. You would be interested in the first half. Then, you would be able to test this part of the editor functionality and APIs which don't require the DOM to work.

Is the second option worth the fuss? I don't think so. The architecture allows removing the DOM dependency but if what you really test is a frontend application then you should care about the DOM.