The rationale is that it’s a very important feature of XS and thats why it must be well tested in the CKEditor module itself.
There’s very little reasons it would fail outside of it. And the cost of testing with all the other modules is too high for the small risk of failure (which will happen for sure).
So you’re right ofc that testing everything with the WYSIWYG editor will reveal more problems, even if 99% of the cases are useless. My issue is that we’d pay a too high price for the 1%.
A good example could be the “inline macro editing” feature we added a while back. Where should tests for it be? First, in the CKEditor project for sure since we provide a contract for macros (they need to use the proper HTML) and if the macros follow it then the WYSIWYG should work fine. Now we probably also need to add tests in the macros themselves to make sure they follow the contract. But we don’t need to add integration tests for all editable macros because that’d take a lot of time to execute and testing that they follow the contract (testing the generated HTML) is enough to guarantee a good level of confidence (even if there can be problems).
Basically my POV we should have the max number of unit tests and the min number of functional tests because we won’t scale otherwise (we already don’t). It also makes it simpler and faster to debug.
WDYT?
@mflorea, @tmortagne you haven’t express your POV recently and it’s discussion between Simon and myself lately 
I’d be curious to hear your POV.