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/