tests/org.eclipse.e4.enterprise.installer.test.integration.fixture/README

What is this?

Test fixtures for testing updating from version X to version Y.

products/*  -- Minimal platform with installer
sites/*     -- Update site to update platform to specified destination version
			   (don't want to use full update site because we don't want to update the bootstrapper)

The table below summarizes for each release if the "driver bundle" is the RCP Example 
or the Bootstrapper and which API was the "default" API path through the installer 
for that release:

4.0.0 - RCP Example  -> BundleUpdater#update(String) 
4.1.1 - RCP Example  -> BundleUpdater#update(String) 
4.2.0 - Bootstrapper -> BundleUpdaterHelper#updateWithProgressDialog() -> BundleUpdater#update(String)
4.3.0 - Bootstrapper -> BundleUpdaterHelper#updateWithProgressDialog() -> BundleUpdater#update(String)
4.4.1 - Bootstrapper -> BundleUpdaterHelper#updateWithProgressDialog() -> BundleUpdater#update(URL, File)

The installer test verifies the following:

Given versions V(4.0.0) to V(4.n), for all V(x), the installer test ensures that we can 
successfully update from V(x) to V(x+1), V(x+2), ..., V(n).

In each case, we do *not* update the "driver bundle" (ie: the RCP example bundle or the 
bootstrapper), but only the installer, and verify that the resulting installation works.  We
also test some other minimal invariants.  This results in the following observation from the 
above table:

For versions 4.0.0-4.3.0, the default installer execution path always went through 
#update(String).  For versions subsequent to 4.3.0, the default installer execution path goes
through #update(URL, File).

Consequently, the platform fixture for versions 4.0.0-4.3.0 will only execute the #update(String)
code path.  Similarly, versions after 4.3.0 (noninclusive) will only execute the #update(URL, File)
code path.  Since the various #update methods are only convenience methods that delegate to
the "real" #update method and don't do any work of their own, this seems like a reasonable 
compromise over testing all permutations of #update methods for each pair of version upgrades.

Lastly, version 4.4.0 removed all permutations of the legacy #update(String) method.  For testability
and to ease customer migration, 4.4.1 adds back a single #update(String) method but marks it as
@deprecated.  This will enable all customers who used the default installer code path up through 4.3.0
to upgrade to 4.4.1 without needing to also upgrade their bootstrapper.  They can then upgrade
their bootstrapper separately when needed.

-------------------------------

In order to run the Integration tests contained within this plug-in you need to;

1) Open up install.product and export to a directory somewhere

2) Open up the InstallerIntegrationTest class (under org.eclipse.e4.enterprise.installer.test.integration)

3) Change the EXPORT_DIR constant to match the directory where you exported in Step 1)
	(Don't include any eclipse sub directory)

4) Right click InstallerIntegrationTest and click "Run as Junit test"

---------

Problems writing an integration test for upgrade problem:

1) Unlike all the other tests, this test must start with a fixture that is at a specific version.

What this is *really* chasing is: Can we upgrade from any prior version of the platform to the current
version and guarantee that (1) it works, and (2) there is some minimal consistent behavior.