OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Interoperable ODF tests using ODF Changes


Dear SC,


When we were discussing on this list how a paragraph within an image would be rendered by applications, I was doing quite a lot of manual testing to see how other ODF application deal with this case. And I suddenly remembered that I did a lot of similar manual interoperability testing when working on ODF interoperability testing before.


Triggered by this experience, I wondered if it is possible to automate easily the creation of a specific document by various ODF applications to test interoperability.

I started some quick tests end of last year, when I stumbled over an open-source automated GUI testing library from the MIT called Sikulix.


Sikulix is quite special as it solely relies on computer vision and searches for thumbnails/graphics and clicks them according to a test script. This approach is therefore possible for any GUI testing. No other interface is required, though there are better specialized frameworks such as Selenium for Web and the Microsoft (MS) UI Framework for testing accessibility of MS Applications.

But the charm of Sikulix was to me the ability to automate the creation of ODF documents for ANY ODF application with or without API by using simply the screen. The scripts can be created by any user with close to none programming knowledge and be able to handle all ODF apps similar is very tempting. Let me explain, why.

I am currently investigating how we can separate the script of the creation of a huge document into calls of different features. Handling an ODF application similar to a state machine and designing it on a higher level via an DSL as VeraPDF is doing their syntax and rules description for validation on PDF (PDF, 0,75MB), which comes without any grammar.


The big advantage would be to feed these automated GUI tests for any ODF application not only with a common ODF feature API, but to use the same change API as used for ODF change-tracking and which is being standardized.

Think about it! We would take a document, drop it into the (potential) upcoming ODF toolkit including the OX change API and receive a sequence of changes representing this document.


This sequence would be used to trigger automated document creation for every ODF application that users have offered GUI support. I am looking forward to do a proof of concept for the FOSDEM!


The higher idea behind is to automate the creation of a document by an ODF application using a MCT change list. The advantage would be that a test once written for an ODF application could be reused by any other application.

Please note that Sikulix due to its manual requirement might not be not a good final choice for testing, but might be nice for prototyping. Basically, MCT could be mapped to any office testing framework.


Long story short, I am trying to gather interest for MCT from a different angle.


See you tomorrow,

Svante



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]