Re: [xwiki-devs] [xwiki-notifications] r13481 - in enterprise/trunk/distribution-test: . wysiwyg-tests wysiwyg-tests/src wysiwyg-tests/src/test wysiwyg-tests/src/test/it wysiwyg-tests/src/test/it/com wysiwyg-tests/src/test/it/com/xpn wysiwyg-tests/src/test/it/com/xpn/xwiki wysiwyg-tests/src/test/it/com/xpn/xwiki/it wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/framework
jvdrean (SVN) wrote:
Author: jvdrean Date: 2008-10-10 11:53:57 +0200 (Fri, 10 Oct 2008) New Revision: 13481
Log: XE-319 : Write an integration tests framework for the new wysiwyg editor
Initial version, the XHTML assertions must be reviewed since some behaviors looks weird.
Should we test the internal HTML? Or the generated wiki syntax? Marius, do all the browsers have the same markup? AFAIK, no, so this is a point against testing HTML. Testing the wiki syntax implies testing not just the editor, but also the html parser. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Sergiu Dumitriu wrote:
jvdrean (SVN) wrote:
Author: jvdrean Date: 2008-10-10 11:53:57 +0200 (Fri, 10 Oct 2008) New Revision: 13481
Log: XE-319 : Write an integration tests framework for the new wysiwyg editor
Initial version, the XHTML assertions must be reviewed since some behaviors looks weird.
Should we test the internal HTML? Or the generated wiki syntax? Marius, do all the browsers have the same markup? AFAIK, no, so this is a point against testing HTML. Testing the wiki syntax implies testing not just the editor, but also the html parser.
One of the things I'm working on is to make all browsers generate the same markup, because the problem is not only that each browser generates its own markup but also that they expect and behave right under specific markup, while the input of the editor is just one, comes from the rendering and is browser independent. I don't think we should test the generated wiki syntax with Selenium. This part is well covered in Vincent's unit tests. I think JV should focus on editor behavior, which sometimes requires inspecting the generated HTML (like in the case of "Return should generate a new paragraph"). We need functional tests for the editor as for an independent widget.
Marius Dumitru Florea wrote:
Sergiu Dumitriu wrote:
jvdrean (SVN) wrote:
Author: jvdrean Date: 2008-10-10 11:53:57 +0200 (Fri, 10 Oct 2008) New Revision: 13481 Log: XE-319 : Write an integration tests framework for the new wysiwyg editor
Initial version, the XHTML assertions must be reviewed since some behaviors looks weird. Should we test the internal HTML? Or the generated wiki syntax? Marius, do all the browsers have the same markup? AFAIK, no, so this is a point against testing HTML. Testing the wiki syntax implies testing not just the editor, but also the html parser.
One of the things I'm working on is to make all browsers generate the same markup, because the problem is not only that each browser generates its own markup but also that they expect and behave right under specific markup, while the input of the editor is just one, comes from the rendering and is browser independent.
I don't think we should test the generated wiki syntax with Selenium. This part is well covered in Vincent's unit tests. I think JV should
JV is working on the DSL for the functional tests. Me and Marcela are going to write them. We might need help, depending on how long it will take to write them (supposedly not too long).
focus on editor behavior, which sometimes requires inspecting the generated HTML (like in the case of "Return should generate a new paragraph"). We need functional tests for the editor as for an independent widget. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Oct 13, 2008, at 11:52 AM, Marius Dumitru Florea wrote:
Sergiu Dumitriu wrote:
jvdrean (SVN) wrote:
Author: jvdrean Date: 2008-10-10 11:53:57 +0200 (Fri, 10 Oct 2008) New Revision: 13481
Log: XE-319 : Write an integration tests framework for the new wysiwyg editor
Initial version, the XHTML assertions must be reviewed since some behaviors looks weird.
Should we test the internal HTML? Or the generated wiki syntax? Marius, do all the browsers have the same markup? AFAIK, no, so this is a point against testing HTML. Testing the wiki syntax implies testing not just the editor, but also the html parser.
One of the things I'm working on is to make all browsers generate the same markup, because the problem is not only that each browser generates its own markup but also that they expect and behave right under specific markup, while the input of the editor is just one, comes from the rendering and is browser independent.
I don't think we should test the generated wiki syntax with Selenium. This part is well covered in Vincent's unit tests. I think JV should focus on editor behavior, which sometimes requires inspecting the generated HTML (like in the case of "Return should generate a new paragraph"). We need functional tests for the editor as for an independent widget.
I don't think testing the generated syntax is a problem (see my other mail). However it's true that some tests (all?) need to verify the generated HTML after some keys are hit and we probably can''t test this by testing the generated syntax (which can be correct because it's been fixed by the HTML cleaner for example or which can be wrong visually (cursor problem) and be correct when the doc is saved). So maybe the dream of having a test suite that works for any wysiwyg editor is doomed? (or maybe it can still work but needs a larger abstraction layer) Let's start writing some tests and see how it goes. Thanks -Vincent
Vincent Massol wrote:
On Oct 13, 2008, at 11:52 AM, Marius Dumitru Florea wrote:
Sergiu Dumitriu wrote:
jvdrean (SVN) wrote:
Author: jvdrean Date: 2008-10-10 11:53:57 +0200 (Fri, 10 Oct 2008) New Revision: 13481 Log: XE-319 : Write an integration tests framework for the new wysiwyg editor
Initial version, the XHTML assertions must be reviewed since some behaviors looks weird. Should we test the internal HTML? Or the generated wiki syntax? Marius, do all the browsers have the same markup? AFAIK, no, so this is a point against testing HTML. Testing the wiki syntax implies testing not just the editor, but also the html parser. One of the things I'm working on is to make all browsers generate the same markup, because the problem is not only that each browser generates its own markup but also that they expect and behave right under specific markup, while the input of the editor is just one, comes from the rendering and is browser independent.
I don't think we should test the generated wiki syntax with Selenium. This part is well covered in Vincent's unit tests. I think JV should focus on editor behavior, which sometimes requires inspecting the generated HTML (like in the case of "Return should generate a new paragraph"). We need functional tests for the editor as for an independent widget.
I don't think testing the generated syntax is a problem (see my other mail). However it's true that some tests (all?) need to verify the generated HTML after some keys are hit and we probably can''t test this by testing the generated syntax (which can be correct because it's been fixed by the HTML cleaner for example or which can be wrong visually (cursor problem) and be correct when the doc is saved).
So maybe the dream of having a test suite that works for any wysiwyg editor is doomed? (or maybe it can still work but needs a larger abstraction layer)
Let's start writing some tests and see how it goes.
We could have a bit of both. Where it's important to test a specific HTML structure, for example to test that the jumping cursor does not occur, we can test the HTML. But this is, IMHO, low level testing. When we want to test the editor as a tool, we should test end-to-end: give a sequence of actions, assert the generated wiki markup. Verify complete user stories, not local bugs. And a user cares about what he gets in the end, not what the intermediate DOM contains. Since the editor is such a graphical tool, and a user's tool, we should have user story tests, right? -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Oct 10, 2008, at 8:34 PM, Sergiu Dumitriu wrote:
jvdrean (SVN) wrote:
Author: jvdrean Date: 2008-10-10 11:53:57 +0200 (Fri, 10 Oct 2008) New Revision: 13481
Log: XE-319 : Write an integration tests framework for the new wysiwyg editor
Initial version, the XHTML assertions must be reviewed since some behaviors looks weird.
Should we test the internal HTML? Or the generated wiki syntax? Marius, do all the browsers have the same markup? AFAIK, no, so this is a point against testing HTML. Testing the wiki syntax implies testing not just the editor, but also the html parser.
We need to have a test that would work the same with, say, our current TinyMCE editor so my initial idea was to test the generated XHTML (i.e. just before the XHTML parser). However you're right that maybe the XHTML would be different (although we should control what we generate). So I agree that testing the generated wiki syntax is probably the best since this is what we want to assert anyway in the end. +1 for testing the wiki syntax. Note: It doesn't matter at all that we retest what the rendering is testing because 1) the goal of these tests are to be functional (aka end to end tests) and 2) we won't test the same things. The unit tests are comprehensive whereas here we only want to test editor behaviors. Thanks -Vincent
participants (3)
-
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol