3.0 Core Test Plan

No config.ini

• install Eclipse
• delete the configuration dir
• start Eclipse
• confirm that everything goes smoothly. The only thing that should be different is the lack of splash screen.
• Note: There may be an issue with the eclipse.product not being set and the runtime not knowing which application to run. We may no longer be able to run without a config.ini. If there is a strong usecase for this then we could embed a valud in eclipse.properties if we had to.

Exit data

• set the exit data system property to a string value
• exit Eclipse with the an error code other than 0, 23 or 24 and ensure the exit data string is properly displayed

Restart

• start Eclipse, use the VM, commands and vmargs System properties to construct a new command line
• set this new command line in the exitdata
• exit Eclipse with return code 24
• confirm that the specified command was run on restart

Command line options

• try various command line options and ensure that the corresponding system property values are set. In particular,
  • -configuration
  • -product
  • -application
  • -install
  • -data

Shared Install 1

• install Eclipse on shared drive
• run once with -initialize, mark read-only
• run one instance, exit
• run another instance (as different user or on different machine), exit
• run two instances at the same time (as different users or on different machines)
• exit in same order as start (i.e., start 1, start 2, exit 1, exit 2)

Shared Install 2

• install Eclipse on shared drive
• run once with -initialize, mark read-only
• run user instance, exit
• start admin instance (with read/write permissions)
• install new features using update manager, exit
• restart previous user instance
• confirm that newly installed features are present and funcitonal
• check that no additional files have been written in the local configuration area

Shared Install 3

• install Eclipse on shared drive
• run once with -initialize, mark read-only
• run one instance
• install new features using update manager
• restart. New features should be there and totally functional
• start another instance as the same user on the same machine
• previously installed features should be present and functional
• start another instance on a different machine or as a different user
• previoulsy installed features should NOT be present

JAR'd plugins

• populate an update site with the Core Tools feature and plugins/fragments. mark the relevant feature entries as unpack=false.
• start Eclipse and install the Core Tools feature using update manager
• check that the plugins and fragments did not get exploded
• confirm that the Core Tools function as expected

Extension registry

• install a plug-in dynamically and check whether its extensions and extension points are properly added to the registry
• remove it and ensure its extensions and extension points go away
• do the same as above with two plugins where one of them requires the other.
• do the same as above with a plugin and a fragment, where both contribute extensions/extension points.
• ensure plugin manifests with valid XML but missing required elements/attributes in extensions/extension points markup are properly ignored/handled

Note: use the org.eclipse.core.runtime/registry/debug/events/extension debug option to monitor registry change events

Nested jars

• Zip the Junit folder such that the files are at the root of the archive, and rename the archive to have .jar as extension
• Delete the JUnit folder
• Start eclipse
• In the console type

   install reference:file:/
   refresh 
   ss
  

  Check that the junit plugin is installed and resolved. Run a Junit test.

Code in folders

• Unzip the content of the original JUnit.jar into a folder named "code"
• In the plugin.xml replace >library name="junit.jar"< by >library name="code/"<
• Start eclipse
• In the console type

   install reference:file:/
   refresh 
   ss
  

  Check that the junit plugin is installed and resolved. Run a Junit test.

Folders in a Jar

• Zip the content of the Junit folder from the previous test in such a way that plugin.xml is that the root of the archive
• Start eclipse
• In the console type

   install reference:file:/
   refresh 
   ss
  

  Check that the junit plugin is installed and resolved. Run a Junit test.

Test concurrent operations in UI thread

• Enable Always run in background preference
• Start checkout of platform-core module from CVS
• During checkout, switch to the Java perspective
• UI may become blocked, but should eventually become responsive
• Open Path.java in Java editor
• Switch back to CVS perspective
• Start checkout of org.eclipse.jdt.ui.tests.refactoring (or other big project)
• Open Navigator: New files should start appearing
• Add breakpoint to a method in Path.java: should appear quickly
• Remove breakpoint: should be responsive
• Start typing in Path.java: Should not block
• Save Path.java: Should not block
• Start typing in Path.java again: Should not block
• Revert file: Should not block

Many background tasks

• Start CVS checkout of ten or more different projects
• Open progress view (double-click in lower right hand corner of workbench window)
• All checkout tasks should be making progress
• Canceling the checkouts should respond in a timely manner.

Nested blocking acquires

• Install the org.eclipse.ui.examples.job plugin
• Load org.eclipse.ui.examples.job
• Open the Job Factory view
• Check "Lock the workspace"
• Click "Create Jobs"
• Change quantity to 3 and duration to 10 seconds
• Click "Touch Workspace"
• Cancel the Test Job
• Dialog should close
• Repeat all above steps except cancel the blocked operation instead of the test job (three times)
• Dialog should close but test job should continue running

Shutdown while job is running

• Start a long CVS checkout
• File > Exit.
• A progress dialog will appear indicating that the operation is waiting.
• Expand Details area and cancel the CVS checkout
• Exit should now complete in a timely manner

test1

• item 1

test1

• item 1

test1

• item 1

Encoding - Content types

• confirm that the right content type is selected when a complex hierarchy of content types exist (use the resource properties dialog to see the content type that was chosen):
  • a .xml file is recognized as XML
  • a .xml file whose root element is <project> is recognized as an Ant Build Script
  • a plugin.xml file is recognized as a Plugin Manifest file
  • a plugin.xml file whose root element is <project> is recognized as an Ant Build Script
• try the same as above with partial/empty XML files - whenever a file has a .xml extension, it should at least be recognized as XML. If the contents are complete enough (root element can be parsed), more specific content types (such as Ant scripts) should be picked.
• confirm that the right encoding is picked for XML files containing a "encoding" attribute or not (default is UTF-8)
• this is a list of all content types in the SDK:
  • org.eclipse.core.runtime.text
    • org.eclipse.core.runtime.xml (*.xml, .classpath, .properties)
      • org.eclipse.ant.core.antBuildFile (*.xml with a <project> root element)
      • org.eclipse.pde.core.pluginManifest (plugin.xml)
      • org.eclipse.pde.core.fragmentManifest (fragment.xml)
    • org.eclipse.jdt.core.javaProperties (*.properties)
      • org.eclipse.pde.core.pluginProperties (plugin.properties)
    • org.eclipse.jdt.core.JARManifest (MANIFEST.MF)
    • org.eclipse.jdt.core.javaSource

Encoding - BOMs

• confirm text files (or any derived content types such as XML and Java source files) are said to have the right encoding when they present a Byte Order Mark (use Notepad to generate those)
• confirm opening such files works ok
• confirm encoding of files with BOM can be overridden by setting a user-specified encoding

Encoding - Preferences

• check the encoding-related info is properly updated when changes are made directly to the underlying preferences file (<project>/.settings/org.eclipse.core.resources.prefs) - try editing the file in a text editor, deleting the file, making the file out-of-sync

Plugin with "." on the classpath

• Using the "new plugin wizard" create a plugin named Dot1 with "." as a jar name.
• Export it as a zip. Verify that the classes are not into a jar.
• Export it as folder. Verify that the classes are at the root of the folder.

Compiling against a plugin with "." on the classpath

• Create a plugin named Normal
• add a dependency to Dot1 in the plugin.xml
• add a code dependency from a class in Normal to a class in Dot1
• try to export Normal
• try to export Normal and Dot1
• confirm that no compile errors occured (if there were you would get an error dialog at the end of the export)

Plugin with a folder on the classpath

• Create a plugin named Folder1 with "myFolder" as a jar name
• edit the build.properties and add a slash after myFolder in bin.includes property
• Export as folder, verify that the class files are rooted in a folder called myFolder

Testing the build order

• in the plugin Folder1, add the following things in the runtime section of the plugin.xml

      <library name="yourFolder">
         <export name="*"/>
      </library>
      <library name="library.jar">
         export name="*"/>
      </library>
	

• replace the content of the build.properties by

source.myFolder = src/
output.myFolder = bin/
source.yourFolder = src/
output.yourFolder = bin/
source.library.jar = src/
output.library.jar = bin/
bin.includes = plugin.xml,\
               myFolder/,
               yourFolder/
jars.compile.order = yourFolder, library.jar, myFolder

• generate manually the build.xml and verify that the build.jars target successively and in this order list yourFolder, library.jar and myFolder

Reuse the plugin Normal

• add a dependency to Folder1
• add a code dependency from a class in Normal to a class in Folder1
• Export Normal
• Export Normal and Folder1

Export of qualified plugins

• Create a plugin Qualified where the version number ends is 1.0.0.qualifier.
• open the build.properties and add

  qualifier = context

• Export the plugin as zip and verify that the name of the zip has 1.0.0.
• Export the plugin as folder and verify that the folder as the name 1.0.0.
• Verify that the version number of the feature in the feature.xml has been updated
• change the build.properties to

  qualifier = NONE

• Export the plugin as zip and verify that the name of the zip is 1.0.0
• Export the plugin as folder and verify that the name of the directory is 1.0.0
• change the build.properties to

  qualifier = myValue

• Export the plugin as zip and verify that the name of the zip is 1.0.0.myValue
• Export the plugin as folder and verify that the name of the directory is 1.0.0.myValue

Export of qualified features

• Create a feature QualifiedFeature, set the version number as 1.0.0.qualifier (don't need to add a plugin in the feature)
• repeat the same steps as in the test with plugin

Export of qualified plugins and features

• Take the feature previously created
• add the plugin "Qualified" in the feature
• Export the feature and verify that the feature.xml content has been updated (the reference to Qualified has the number from the "Qualified" plugin)
• Verify that the version number of the feature in the feature.xml has been updated

Export of nested features with qualifiers

• create a new feature (no importance in the name and version)
• add the newly created feature to this feature
• export the "QualifiedFeature" feature and verify that the feature.xml has been updated properly

Test of optional matching rules

• Create a plugin named Match1
• Create a plugin named Match2
• Update Match2 dependencies to optionaly requires Match1
• Close Match1 project
• Generate the build.xml (right click on plugin.xml)
• If the build.xml is generated it is ok

Tests of matching rules

• Re-open the plugin named Match1
• Update Match2 dependencies to have a dependency on Match1 which is version="1.0.0" match="perfect"
• Generate the build.xml (right click on plugin.xml)
• If the build.xml is generated it is ok
• Repeat steps 2, 3 and 4 for the 3 different values for matching rules

  version="1.0.0" match="perfect"
  version="1.0.0" match="equivalent"
  version="1.0.0" match="compatible"
  version="1.0.0" match="greaterOrEquals"
  

• Change Match1 version number to be 1.0.1 and repeat the "repeat section". The test with perfect match is expected to fail.
• Change Match1 version number to be 1.1.0 and repeat the "repeat section". The tests with perfect and equivalent are expected to fail.
• Change Match1 version number to be 2.0.0 and repeat the "repeat section". The tests with perfect, equivalent and compatible are expected to fail.

Startup