16 Oct
2008
16 Oct
'08
7:38 p.m.
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.