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
10 Oct
2008
10 Oct
'08
8:34 p.m.
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/
13 Oct
13 Oct
11:52 a.m.
New subject: [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
Sergiu Dumitriu wrote:
jvdrean (SVN) wrote:
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.
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.
12:41 p.m.
New subject: [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
Marius Dumitru Florea wrote:
Sergiu Dumitriu wrote:
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).
jvdrean (SVN) wrote:
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 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. 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
16 Oct
16 Oct
7:38 p.m.
New subject: [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
On Oct 13, 2008, at 11:52 AM, Marius Dumitru Florea wrote:
Sergiu Dumitriu wrote:
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
jvdrean (SVN) wrote:
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. 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.
17 Oct
17 Oct
2:38 a.m.
New subject: [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
Vincent Massol wrote:
On Oct 13, 2008, at 11:52 AM, Marius Dumitru Florea
wrote:
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/
Sergiu Dumitriu wrote:
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. jvdrean (SVN) wrote:
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. 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.
16 Oct
16 Oct
7:22 p.m.
New subject: [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
On Oct 10, 2008, at 8:34 PM, Sergiu Dumitriu wrote:
jvdrean (SVN) wrote:
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
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.
5816
days inactive
5823
days old
5 comments
3 participants
participants (3)
-
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol