QA/test automation guide
VCLAuto [Planning]
Introduction
VCLAuto is a Java library for OpenOffice UI/functional testing like VCL TestTool. VCLAuto can be used with JUnit. The project is under developing and will be released in Apache OpenOffice 4.0.
There are a lot of testing codes in the OO project, e.g. unit test, qadevooo and smoketestoo_native. Why do we need the library? Generally, unit test code (pure junit/cppunit test) is executed in the build process before OO is created. It's low-level and used to verify if the source code is right before they are linked to a real product. It's a white-box testing. If you want to verify a function/method/interface is correct, put your test code in unit test. qadevooo & smoketestoo_native uses UNO API/Macro to perform testing. To run them, a real OO product must be available. It's middle-level and used to verify if UNO api and business model work correctly. It's a gray-box testing. User interaction is not involved in this testing. It can't fully simulate a user behavior or check if GUI is correct. For example, check if user can draw a shape by dragging, check if OO automatically capitalize the first letter after typing a word, check if a button's checked when user change the selection, etc. Vclauto is high-level black-box testing. It performs testing more like a real user. It generates keyboard/mouse events, does GUI actions and gets information from the GUI to validate the function.
Background Actually VCLAuto is a java version of VCL TestTool, which connects to the automation server (automation module) in OpenOffice with socket. With the "-enableautomation" argument, OpenOffice will start the server with listening on the port 12479 be default. VCL TestTool is heavily used by the QA team in SUN/Oracle, but many people doesn't like it because of its drawbacks.
- The poor IDE. (Java has many enough powerful IDEs to make writing code easily, e.g. Eclipse / Netbeans)
- Hard to debug.
- Hard to read the code and analyze the testing result. (A lot of code is written in Non-English. Maybe German)
- Too many errors
- Basic language is not popular.
I found http://wiki.services.openoffice.org/wiki/Test_Cleanup starts to unify all testing code to following the standard xUnit style, so I think it's time to clean up GUI test as well.
Code
Write UI testing case following JUnit 4 style like the following:
public class UITest { @Before public void setUp() throws Exception() { initApp(); } @Test public void test() throws Exception() { // Create a new text document via main menu startcenter.menuItem("File->New->Text Document").select(); typeKeys("Hello OpenOffice"); writer.menuItem("Edit->Select All").select(); // Copy the text typeKeys("<$copy>"); assert("Text is inputted successfully.", "Hello OpenOffice", App.getClipboard()); } @After public void tearDown() throws Exception() { } }
The library mainly implements a bunch of vcl control proxies to perform actions on and retrieve information from OpenOffice. e.g.
VclControl startcenter = new VclControl("startcenter.id"); startcenter.click(); VclButton someButton = new VclButton("some.button.id"); someButton.click(); boolean checked = someButton.getText(); VclListBox someListBox = new VclListBox("some.listbox.id"); someListBox.select("Item1"); String selected = someListBox.getSelText();
Methods to post keyboard/mouse event to OS. typeKeys("AB<enter>");
TODO Provide command to run the test after OpenOffice installation set is built out.
Use Apache Ant to Run Testing and Generate Report