Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Common Build Infrastructure/Testing

< Common Build Infrastructure
Revision as of 17:43, 1 February 2010 by Nickboldt.gmail.com (Talk | contribs) (References)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Warning2.png
Draft Content
This page is currently under construction. Community members are encouraged to maintain the page, and make sure the information is accurate.


Running Tests As Part Of An Athena Build

Simply use these build.steps entries to build, then run, your tests. Or omit the property entirely in your build.properties file and the default steps will be run:

build.steps=buildUpdate,buildTests,generateDigests,testLocal,publish,cleanup

Note that the previous test runner task, "test" is still available but only works on Linux as it requires xvnc or xfvb.

Run Tests In Hudson

To use the new testLocal task, you will need to enable Xvnc to run around your entire build.

Hudson-Enable-Xvnc-Wrapper.png

To use the old test task, you will need to run your tests on a Linux server with xvnc or xvfb installed.

Running Tests Separately From An Athena Build

Option 1. Run Tests Again

After a successful build, you may want to re-run the same tests.

Point your build.properties at the previous build's timestamp and it will re-run the tests in that same folder (destructively).

build.steps=testLocal
buildTimestamp=200911232255

Yes, that's it - just point at a pre-existing timestamp, and you're good to go!

Option 2. Run Tests Separately From a Previous Build

Point your build.properties at the paths where the Tests and Update zips can be found.

If you normally build with repositoryURLs and featureIDsToInstall, add the values below to those existing properties - DO NOT replace! You will of course need to define all the runtime/compiletime dependencies as you would for a normal build or build+test run.

Local Inputs

build.steps=testLocal,publish,cleanup
testFramework=/path/to/GEF-Automated-Tests-N200911232255.zip
repositoryURLs=jar:file:/path/to/GEF-Update-N200911232255.zip!/
featureIDsToInstall=${mainFeatureToBuildID}

Remote Inputs

build.steps=testLocal,publish,cleanup
testFramework=http://path/to/GEF-Automated-Tests-N200911232255.zip
repositoryURLs=http://path/to/GEF-Update-N200911232255.zip
featureIDsToInstall=${mainFeatureToBuildID}

To prevent cleanup, you can either omit the build.steps=publish,cleanup steps, or use

noclean=true

References

Controlling Test Environment

You can pass a custom library file (to replace org.eclipse.test/library.xml) or set different Java heap/permgen settings when running your tests. This is particularly important when debugging or running on 64-bit platforms, which need more memory allocation than 32-bit platforms. See Testing - VMArgs for details.

Back to the top