PDE Test Scenarios

Note that the different scenarios are independent of each other and can be executed in any sequence.

The test plan is designed and edited so that it can be executed in a reasonable amount of time.  Emphasis is therefore placed on functionality added during the 3.2 cycle.

If you find a problem with a scenario step:

1. Open a Bugzilla defect against the PDE/UI component after ensuring that no one else has already opened a bug report.
2. Include the build number (e.g. 3.2RC2 , 3.2RC3etc.).
3. Prefix the Summary of the defect with the step number (e.g. B1.1, C2.4)

Setup

• To be able to run the scenarios exactly as described below, you need Eclipse 3.2 RC2 (or later) installed.
• Two steps that need to be done before executing any of the scenarios.
  • Launch Eclipse on a new workspace.
  • Dismiss the Welcome Page by clicking on the Go to Workbench icon.
• At the end of each scenario, it is recommended to delete all projects from your workspace so that one part does not interfere with the next.

Scenario A:  End-to-End Scenarios

If your last name (as it appears on your badge) ends with a vowel, do part A1.  Otherwise, do part A2.

A1.  A Full Plug-in Development Cycle

1. From the top level menu, select Help > Cheatsheets... > Plug-in Development > Creating an Eclipse Plug-in.  Press OK.
2. Go through this cheatsheet to explore all stages of the plug-in development cycle.

A2.  Creating an Rich Client Application

1. From the top level menu, select Help > Cheatsheets... > Plug-in Development > Creating a Rich Client Application.  Press OK.
2. Go through this cheatsheet to create a standalone, fully-branded rich client application.

Scenario B:  Search

B1.  Classic Plug-in Search

1. From the top level menu, select Search > Search... to bring up the Search dialog.
2. Click on the Plug-in Search tab.  Enter *.debug.ui.* as a search string.  Leave all defaults as-is.  Press the Search button.
3. Verify that the Search view opens and that it contains 31 hits.
4. Double-click on the first hit to open the manifest editor of the org.eclipse.debug.ui plug-in.
5. Verify that the editor opens to the plugin.xml source page and that the extension point ID is visible and correctly selected.  Also verify that the arrow in the margin is on the correct line.
6. Using the Down Arrow in the Search view toolbar, navigate to the next hit.
7. Verify that the manifest editor for the org.eclipse.ant.ui plug-in opens with the extension hit visible and correctly selected.
8. Press the Down Arrow again.  Verify that the selection moves to another hit within the same editor.  Verify that a new editor does NOT open.
9. Close all manifest editors.

B2.  Plug-in Search in Mixed Namespaces

1. Bring up the New Plug-in Project creation wizard via File > New > Project... > Plug-in Project.  Press Next.
2. Enter com.example.xyz as the project name.  Press Next.
3. Accept all defaults and press Finish.  Answer Yes when prompted to switch to the Plug-in Development perspective.
4. On the Extension Points page of the plug-in manifest editor, press Add...
5. Enter org.eclipse.pde.core.parsers as the extension point ID.  Enter Parsers as the extension point name. 
6. Uncheck the checkbox to edit the extension point schema.  Press Finish.
7. Verify that the extension point was created.  Save the file and close the editor.
8. Bring up the search dialog via Search > Search... from the top level menu.
9. On the Plug-in Search tab, enter org.eclipse.pde.core.* as the search string.  In the Limit To group, select Declarations.  Press the Search button.
10. Verify that the search view opens with 5 matches.
11. Double-click on the org.eclipse.pde.core.parsers search hit.  Verify that it correctly locates the extension point on the plugin.xml source page of the com.example.xyz plug-in.
12. Double-click on the org.eclipse.pde.source search hit.  Verify that the extension point declaration is correctly located on the plugin.xml source page of the org.eclipse.pde.core plug-in.

B3.  PDE as a Java Search Participant

1. Check out the org.eclipse.pde.core plug-in project from HEAD.
2. Right-click on the org.eclipse.pde.core.plugin package and select References > Workspace from the context menu..
3. Verify that you get a search hit in the MANIFEST.MF file of the plug-in.
4. Double-click on the search hit.  Verify that the manifest editor opens on the MANIFEST.MF source page with the org.eclipse.pde.core.plugin package highlighted in the Export-Package header.
5. Close the editor.
6. In the Package Explorer view, select References > Workspace from the context menu of the org.eclipse.pde.internal.core.variables.TargetHomeDynamicVariableResolver.
7. Verify that you get a search hit in the plugin.xml file of the plug-in.
8. Double-click on the search hit. Verify that TargetHomeDynamicVariableResolver is highlighted in the resolver attribute of the org.eclipse.core.variables.dynamicVariables extension.

Scenario C:  PDE as a Refactoring Participant

C1. Renaming Types

1. Bring up the New Plug-in Project creation wizard via File > New > Project... > Plug-in Project.  Press Next.
2. Enter com.example.abc as the project name.  Press Next.
3. Accept all defaults.  Press Next.
4. Choose the Hello World template.  Press Finish.
5. In the Package Explorer view, select Refactor > Rename... from the context menu of the com.example.abc.Activator type.
6. Enter BundleActivator as the new name and press Finish.
7. Turn to the MANIFEST.MF source tab of the plug-in editor and verify that there is no warning next to the Bundle-Activator header and that its value has been updated to reflect the new type name.
8. In the Package Explorer view, select Refactor > Rename... from the context menu of the com.example.abc.actions.SampleAction type.
9. Enter NewAction as the new name and press Finish.
10. Turn to the plugin.xml source tab of the plug-in editor and verify that there is no warnings in the margin and that the class attribute on line 21 references the new type name.

C2. Renaming Packages and Subpackages

1. Turn to the Runtime page of the manifest editor of the com.example.abc plug-in.
2. In the Exported Packages section, press Add... 
3. Verify that the selection dialog shows two packages.  Select them both and save the file.
4. In the Package Explorer view, select the com.example.abc package and select Refactor > Rename... from the context menu.
5. In the Rename dialog, check the Rename subpackages checkbox.
6. Enter com.example.abc.def as the new package name.  Press Finish.
7. Verify that NO warnings appear on the MANIFEST.MF or the plugin.xml files.
8. Turn to the MANIFEST.MF source tab of the plug-in editor and verify that the Bundle-Activator and Export-Package headers are now referencing the new package name.
9. Turn to the plugin.xml source tab of the plug-in editor and verify that the class attribute on line 21 references the new package name.

Scenario D:  Cool Wizards

D1. Externalize Manifests Wizard

1. Create a Hello World plug-in by repeating steps C1.1 - C1.4
2. Select the com.example.abc plug-in project and select Properties from its context menu.
3. On the Plug-in Development > Plug-in Manifest Compiler preference page, choose the Use project settings option.
4. Raise the severity level for Usage of non-exteranlized strings from IGNORE to ERROR.  Press OK.
5. Answer Yes when prompted to rebuild the project.
6. Verify that the MANIFEST.MF file now has 2 errors and the plugin.xml has 4 errors.
7. Right-click on the com.example.abc project and select PDE Tools > Externalize Strings... from the context menu.
8. Verify that the Bundle-Name and Bundle-Vendor headers in the MANIFEST.MF file are flagged as non-extenalized.
9. Verify that there are four attributes in the plugin.xml that are flagged as non-externalized.
10. Accept all defaults and press Finish.
11. Verify that all errors have gone away.
12. Verify that a plugin.properties file was created at the root of the project containing six key-value pairs.
13. Verify that attributes/headers flagged in steps 8 and 9 now have keys that start with %

D2. Organize Manifests Wizard

1. Check out the org.eclipse.pde.ui plug-in project from HEAD.
2. Open the manifest editor for the org.eclipse.pde.ui plug-in and go to the Runtime tab.
3. In the Exported Packages section, remove the org.eclipse.pde.ui.launcher and org.eclipse.pde.internal.ui.wizards.xhtml from the list.
4. Switch to the plugin.xml tab.  On line 17, remove the $nl/ prefix from the value for the icon attribute.  Save the file.
5. Bring up the Organize Manifests wizard via PDE Tools > Organize Manifests... from the context menu of the org.eclipse.pde.ui plug-in project.
6. Keep all default options.  In the Internationalization section, check the first option.  Press Finish.
7. This should undo the damage done in steps 3 and 4.
8. Select Compare With > Latest from HEAD from the context menu of the org.eclipse.pde.ui plug-in project.
9. Verify that there are no differences.

Scenario E: Target Definitions and Import Management

E1. Loading the RCP Target Definition

1. Open the Target Platform preference page via Window > Preferences... > Plug-in Development  > Target Platform from the top level menu.
2. From the Pre-Defined Targets section at the bottom, select the Base RCP (with source) target.
3. Click on the Target link next to the combo box to view the makeup of the target definition in a new window.
4. Verify that the Features tab lists two features: org.eclipse.rcp and org.eclipse.rcp.source.  Close the Target Preview window.
5. Press the Load Target button.  Verify that only 23 plug-ins are now selected in the list of plug-ins above.  (The count is 23 on Windows.  Number may vary slightly on other platforms).
6. Press OK to apply the changes and dismiss the preferences dialog.

E2. Import Management

1. Repeat steps C2.1 - C2.4 to create a Hello World plug-in project.
2. Go to the Dependencies tab of the plug-in manifest editor and remove the two plug-ins listed in the Required Plug-ins section.
3. Save the file.  Verify that you get compiler errors in the project.
4. Expand the collapsed Automated Management of Dependencies section and press the Add... button in said section.
5. Verify that it lists the plug-ins from E1.5 and not all 111 plug-ins.
6. Add all plug-ins from the selection dialog to the list and save the file.
7. Verify that the code in the plug-in project now compiles again even though there are no plug-ins listed in the Required Plug-ins section.
8. In the Automated Management of Dependencies section, click on the add dependencies link.
9. Verify that the Required Plug-ins list is now re-populated with the org.eclipse.ui and org.eclipse.core.runtime plug-ins.  No more and no less.

When you're done with this scenario, go back to the Target Platform preference page.  Select all plug-ins on that page and press OK.

Scenario F:  Running an OSGi Application

F1. Create an OSGi Bundle

1. Bring up the New Plug-in Project wizard via File > New > Project... > Plug-in Project.  Press Next.
2. Enter com.example.bundle as the project name.
3. In the Target Platform section, choose the OSGi framework option.  Leave Equinox as the selection.  Press Next.
4. Accept all defaults.  Press Next.
5. Choose the Hello OSGi Bundle template.  Press Finish.
6. Verify that the manifest editor opens but does NOT show the Extensions and Extension Points tabs.

F2. Run an OSGi bundle

1. Select Run As > Equinox Framework from the context menu of the com.example.bundle project.
2. Verify that the Console view opens and that it contains an osgi> prompt.
3. Verify that it says Hello World!! at the prompt
4. Press Enter to get a new prompt.  Position the cursor after the > and type ss to display the list of installed bundles.
5. Verify that two bundles are listed as active: the system bundle and the com.example.bundle
6. Type stop 1 at the osgi> prompt to stop the com.example.bundle Bundle.
7. Verify that the message Goodbye World!! is printed to the console.
8. Type ss again at the osgi> prompt.
9. Verify that com.example.bundle is now listed as RESOLVED.
10. Type exit at the osgi> prompt to terminate the launch.