Difference between revisions of "Test Refactor"

Revision as of 00:21, 12 July 2012

The page is created for tracking test refactor project.

Current Status

Currently, there are many modules for testing. Note, the mentioned testing here requires a running OpenOffice instances. That means OpenOffice must be installed before testing. It's not the unit test at the code level. The test code is organized in a mess and out of maintain. Even the most are not stable enough to give useful results. It's hard to get started. Three programming languages (Java, Basic and C++) are used. It's not necessary. The summary is here.

• test

Includes reusable code for UNO API test.

• testgraphical

Test tool to test documents by it's graphical representation.

• testautomation

All test scripts for the old VCL Testtool. Nobody maintains it now.

• smoketestdoc

It's used to generate the test documents required by smoke test.

• smoketestoo_native

A small test suite to verify if the basic functions of OpenOffice.org work.

• qadevOOo

UNO API test, complex test.

• {Module}/qa

UNO API test, complex test.

Target

The target is to reduce module count, organize the testing code clearer, make test code enough stable to integrate with buildbot, and provide more readable test report. We should write all test based on JUnit 4. Test code should be broken down into three categories.

1. purely GUI test. It requires graphical user interfaces enabled. So it can not be performed in headless mode and hard to run in parallel.
2. purely API test. Graphical user interfaces is not required. We can run this kind of test in parallel to save time.
3. Mixed test. This kind of test involves both GUI test and API test. It also can not be parallelized.

Suggest to move all test stuff into test module and create several sub-projects in it:

• test/testcommon

The reusable code for both GUI test and API test, e.g. utilities/helpers.

• test/testuno

API test should implemented in the sub-project.

• test/testoo

GUI test should implemented in the sub-project.

Todo for the existing modules.

• test

Replace it with testcommon

• testgraphical

Re-implement it as JUnit4 testcase in testoo.

• testautomation

Convert the scripts as JUnit4 testcases in testoo. And remove it when testoois enough.

• smoketestdoc

Move it into testoo.

• smoketestoo_native

Re-implement it as JUnit4 testcase in testoo.

Next Step

The two modules (testcommon and testoo) are not involved in the build process. After building out AOO, developers/testers can start testing with some commands. In order not to break build, suggest to create the two new modules firstly. Then migrate the legacy code into the new structure steps by steps. When it works stably, we can remove all the old modules.