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. | |