Setting up CruiseControl & Command Line PDE JUnit Tests
Setting up CruiseControl
and automatically running the test suite appears easy, conceptually, but in practice it is a whole different story. This guide is intended to assist you in this process and was written when re-installing CruiseControl
on a Windows Server 2008 R2 server.
Initial setup (Tests)
- Extract the test framework into a directory; for me it was c:\work\eclipse-testing
- Ensure you have the Eclipse SDK zip file (and all other zip files) in that same folder. The test framework will extract these.
- Ensure that "unzip" is on your path. Unzip comes with cygwin. (As specified by the testing framework's readme.html)
- I already had my c:\cygwin\bin folder in my path.
- There is a runtests.bat file in the folder. Don't run it just yet.
- What this file does is it extracts the current version of eclipse into the test-eclipse folder (creating c:\work\eclipse-testing\test-eclipse\eclipse\*).
- Then, it extracts the tests (which are contained in a zip file that was in the automated testing framework, now in c:\work\eclipse-testing).
- Then, it will look at its command line arguments. You pass an ant task (referring to a test to be executed) as an argument.
- You're ready to run a simple test but it will take a few minutes to run, as it needs to extract a bunch of things.
- SETUP: Set JAVA_HOME to point to a 1.6 32-bit JDK (1.7 does not work with CruiseControl. JRE does not work for compilation. 64 bit does not work with Eclipse) but write the path is like c:\progra~2\java\... instead of c:\program files (x86)\ - ant will crash for no reason otherwise.
- In the dos prompt, type: runtests jdttext
- Specifying a test will save you from having to execute the whole test suite, as we don't care about that one.
- (Not 100% sure) I think this extracts into c:\work\eclipse-testing\eclipse* and then copies everything into c:\work\eclipse-testing\test-eclipse * If all goes well, your unit test will run, Eclipse will open and close, and your tests will pass. However, it won't, as this testing framework is a masochist. See troubleshooting below.
- Once the c:\work\eclipse-testing\test-eclipse\eclipse\* folder exists (after a partial test run), you should always run this, as it is faster: runtests -noclean jdttext.
- In my case, the test doesn't pass for a number of reasons which I describe below. However, at this point, I always run with -noclean and the c:\work\eclipse-testing\eclipse version becomes useless (unless you accidentally delete test-eclipse by forgetting the -noclean option). Everything occurs in the c:\work\eclipse-testing\test-eclipse\eclipse folder. Apologies for the horrible folder names.
- Expect a gazillion different types of errors. Be patient.
- The first error I got with this release was the testing tool looking for an exact filename (eclipse-SDK-M20110909-1335-win32.zip) so I renamed my SDK to have this exact filename instead of the cleaner filename (aka eclipse-SDK-3.7.1.zip) I originally had.
- Then, on one of my machines, it was looking for c:\buildtest\M20110909-1135\\eclipse-testing\eclipse-platform-3.6.2-win32.zip so I downloaded that zip and put it in the desired folder and did not (quickly) find why it wasn't looking in the right folder. Did not happen in my second test.
- At this point c:\work\eclipse-testing\test-eclipse\eclipse\* existed so I manually extracted all the plugins downloaded above into this test version. You don't need these for the PDE Unit Tests, but you do for jUCMNav later on.
- Other types of errors:
- 'I can't find junit.framework.SomethingOrOther' - Delete the JUnit 3.* plug-ins from your c:\work\eclipse-testing\test-eclipse\eclipse\* folder. Delete both the org.junit.*.jar files for version 3 in the plugins folder and any org.junit.* subfolders for version 3. (version 4 includes the version number in the file or folder name)
- "Unable to find org.eclipse.jdt.text.test.xml " or "Looking for " or something similar: the test framework only works on extracted JARs, for some reason. Rename the plugin .jar to zip. Extract the zip into a folder with the same name. It should then find the files it is looking for inside the subfolder.
- Can't find such and such *.jar file even if you have the plug-in installed. Often, it is looking for a file such as junit.jar which is typically included in another jar (and sometimes inside the lib folder of that other jar). I had to copy a bunch of these (especially for compilation in CruiseControl) into the root of the plugins folder.
Testing Work Flow
- This may help you understand what is going on under the hood. This is all relative to c:\work\eclipse-testing.
- runtests.bat runs test.xml via some fancy techniques.
- test.xml lists all of the unit tests that can be executed and invokes the test.xml inside of a plugin via some fancy techniques. the plugin's test.xml must be on the disk (not inside a jar file).
- Ex: test-eclipse\eclipse\plugins\seg.jUCMNav_2.0.0\test.xml
- test-eclipse\eclipse\plugins\seg.jUCMNav_2.0.0\test.xml defines the java classes to be executed as a ui test. the framework runs it in the context of a new Eclipse Instance.
- Install CruiseControl (I got version 2.8.4 which doesn't work properly with Java 1.7) into c:\work\CruiseControl.
- Checkout svn://cserg0.site.uottawa.ca/projetseg/trunk/cruisecontrol into some folder, as it gives you the scripts we've modified.
- Copy c:\work\eclipse-testing\ (all of it) into c:\work\cruisecontrol\testing\. Read all of the above about testing before doing so.
- Checkout jUCMNav into c:\work\cruisecontrol\checkout\get\seg.jUCMNav
- Create c:\work\cruisecontrol\logs\seg.jUCMNav
- In our example, we're publishing our builds on the r:\ drive - ensure that this is present by running map_ccbuilds.vbs
- I had ant 1.8.2 installed and on my path, but I think you could use the one that comes with CruiseControl if you change the script.
- This new version of CruiseControl includes a web interface at http://localhost:8080/dashboard. It lets you start builds and monitor progress.
- See the testing troubleshooting section for details about what could go wrong (compilation and testing).
- The CruiseControl service will not work by default if map-ccbuilds.vbs is not executed beforehand. (still to be resolved)
- I discovered that the htmlemail publisher did not work because it was sending from cruisecontrol AT softwareengineering.ca (which does not exist) to jucmnav-dev AT softwarenegineering.ca (which does exist).
- Run cruisecontrol.bat to launch CC
- CC looks at its config.xml file to discover the seg.jUCMNav project.
- This project says monitor this folder for svn modifications, call build-seg.jUCMNav.xml when it happens, and publish the results via email and a copy to the r:\ drive.
- build-seg.jUCMNav.xml builds, packages and tests jUCMNav.
- build-seg.jUCMNav.xml calls ccbuild.xml in the checked out version of jUCMNav to build & package it.
- ccbuild.xml compiles the application, creates a few jar files and a few zip files.
- the compilation points to a location which includes a bunch of jar files (hence the importance of having all these *.jar files in the root of the plugin directory)
- build-seg.jUCMNav.xml then calls the testing platform with -noclean jUCMNav to run a special test we've added inside testing\test.xml for this purpose. (extracts the zip, runs the test suite, gathers the results)
Below are reminders from previous version of this guide.
- I deleted lots content from this page which no longer appears relevant. View the version history of this page for more information.
- When running the tests, my script used to stop after 3 seconds, saying message 13. I didn't know what this was so I enabled ant assertions in the batch file. Still nothing good.
- After reading posts on eclipse.org for an hour, I was told to check the C:\work\eclipse-testing\workspace\.metadata\.log file. I found this root exception:
java.lang.UnsatisfiedLinkError: C:\work\eclipse-testing\eclipse\plugins\org.eclipse.swt.win32_3.0.1\os\win32\x86\swt-win32-3063.dll: Access is denied
- I changed my filesystem properties on the folder containing this file and, recursively, its children. For some reason, no one had read access.
- This problem is windows specific.
- 31 Jan 2012