Migration information

Various aspects of test structure and database structure may change between versions. For this reason, it is always important to follow these migration steps.Please be aware that we highly recommend updating each version sequentially, and not skipping versions in-between.

Backup your currently used version

Before installing the new version:

Perform an export all of your projects from your current database(s) with your currently used version. This ensures that all projects (including the unbound modules and any other library projects you use) are backed up. You can, if you prefer, export each project separately. It is important that you perform the export with the ''old'' version of the ITE (Integrated Testing Environment).

Be aware: when a project is exported, the test result details for test result reports are not exported. If you wish to keep test result reports over multiple versions, then you should ensure that you keep older database instances and ITE or dashboard versions to access those older databases.

Export your database preferences from your workspace.

Back up any extensions you have written.

In your home directory, rename the .jubula directory to e.g. .jubula-<OLDVERSIONNUMBER>. (The ITE and the AUT Agent must not be running for this to be performed). This ensures that the new log files will be written into a new .jubula directory.

Install the new version

Standalone users

Follow the instructions in the installation manual and the graphical installer to install the new version. We recommend installing each new version in a new folder, whose name includes the version number. In this way, you can keep the older version until the migration is complete.

Plugin users

Install the update into your current Eclipse. If you use tools from the standalone version in your environment (the AUT Agent, for example), ensure that you update (install) these as well.

Set up the new version

Start the new version of the ITE. We recommend using a new workspace for each new version.

Migrating your projects to the new database

If you use the embedded database

We recommend creating a new (different) location for a new embedded database in the preferences in the new ITE before connecting to the database. You should name the new folder with the version number of the ITE you are using.

Connect to the newly configured database from the new version. The database tables will be created and the new versions of the unbound modules projects will be imported.

Users of other (i.e. non-H2) databases

Create a new database scheme. We recommend naming the scheme with the major and minor version numbers of the ITE you are using.

Connect to the newly created database from the new version. The database tables will be created and the new versions of the unbound modules projects will be imported.

Once you have connected to the database, import all of the projects you exported from the older version, including the unbound modules projects (your projects still reference them, and the version can be switched in the next steps). You can use the import dialog to import multiple projects at once - we recommend ordering the projects so that any library projects (unbound modules, your own reused projects) are listed first.

Updating your projects to use the new version of the unbound modules

Perform these steps for all projects in your database - including any projects that you yourself have defined as reused projects for your main project. It is important that all reused projects (including projects indirecty reused by directly reused projects) use the same version of their necessary projects.

Open the project you wish to update.

In the project properties, select Used Projects. You will see the old version of any used projects on the right hand side, and the new versions on the left hand side.

To perform a switch, select the new version and the old version of a project, and press the switch button with the two arrows pointing in different directions.

Press OK.

Refresh the project.

In the new versions of the unbound modules, check the category deprecated for any modules that are marked as deprecated for this version number. You should find these modules (using e.g. F7 or Show where used) or any Test Steps that use these actions in your project and replace them with the newer version from the unbound modules. Where possible, the new module will be referenced in the deprecated modules. Otherwise, search in the relevant category of the unbound modules to find the newer version.

Once the switch has been performed for all unbound modules in all projects, then you can delete the old versions of the unbound modules from the database. Ensure that you select the correct version of the unbound modules to delete!

Updating your continuous integration scripts

As the name of the database and the workspace have changed, you should update any scripts for your continuous integration that use these properties. These can include, but not be limited to, testexec and dbtool, as well as scripts within your build management tool.

Updating your RCP AUTs

Each new version contains a new RCP Accessor. If you test RCP AUTs, ensure that the old version of these is replaced with the new version in your AUT. To do this, please follow the information in the user manual on setting up your RCP AUT for each migration. You may need to start the application with -clean to ensure that the new RCP Accessor is used.

Updating your test machines

If you have installed the AUT Agent on other machines in the network in order to run distributed tests, then you will also need to update the AUT Agent on those machines as well. You can install the AUT Agent separately as an option during installation. Bear in mind that if you use scripts to start the AUT Agent that contain the version number in them, these may also have to be updated.

Uninstall the old version

Once you have successfully performed all migration steps, and have checked that your continuous integration is running smoothly, you can uninstall the old version.

If you require test results from older versions (which are not migrated with projects), then you may wish to keep the older versions and their relevant databases and dashboards.