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/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
