Page tree

Skip to end of metadata
Go to start of metadata

This topic explains how to share projects and related test assets by checking them in and out of your existing source control system.

Sections include:

Sharing Projects and Assets with any Source Control System

Key project artifacts are in ASCII. This makes it easy to maintain them via source control, and merge changes from multiple team members in a concurrent development environment.

To share projects and test assets using any source control system:

  1. Ensure that your test assets (test cases, user-defined stubs, and so on) are stored within your project.
  2. Add the project to source control.

Other team members can access the project files by checking them out from source control.

Using a Team Project Set File (.psf) to Share the Project Across the Team

Once one team member creates a project, that team member can create a Team Project Set File (.psf) which can then be shared by other members of the team. Doing so allows every team member to create their Eclipse Projects in the same uniform way. This is a necessary step for importing tasks from the automated nightly test process.

To export a Team Project Set File:

  1. Select File> Export. The ExportWizard displays.
  2. Within the ExportWizard, select Team> Team Project Set, and then click the Next button.
  3. Select the projects to be included in the Team Project Set File by selecting the corresponding check boxes,
  4. Enter the location where the Team Project Set File will be saved and click the Finish button.

To create a Project from an imported Team Project Set File:

  1. Select File> Import. The Import Wizard displays.
  2. Within the Import Wizard, select Team> Team Project Set, and then click the Next button.
  3. Browse to the desired Team Project Set and click the Finish button. The tests you selected display in the Test Case Explorer.


C++test-Specific Sharing Tips

  1. Check in the necessary project definition files to ensure that the project can be re-created "from scratch". For example:
    • Check in .project, .cdtproject/.cproject [if present - depending on the CDT version], .parasoft [if present], and .settings/* [if present]. These files will be directly in the project directory location. They completely define the contents and settings of the project for C++test.

  2. (Optional) Check in additional resources as desired. For example, you can check in:
    • The original project contents.
    • Tests
    • Stubs
    • Data sources

    Do not check in temporary files

    Do not check in temporary data/files (such as instrumented sources, compiled objects, linked test executables, and automatically-generated header files) with the project. By default, temporary files are in the.cpptest directory of the current workspace. 

    - These files should not be stored in source control because C++test can automatically re-generate these as needed. Moreover, they might include non-shareable information (like absolute paths).

    - If this data is currently being stored within your project, change the C++test temporary files settings as explained in the C++test User’s Guide.

  3. If the project was configured to use options from a build data file, ensure that all users have the .bdf file in a consistent location (as set in the Build data file option in the project properties’ build settings).
    • For example, you could use the project location (with files) for a single bdf. Or, you could use a workspace/temp area based on the project name.
    • Resource location, project location, or environment variables can be used.
    • There is no need to share the .bdf file. All users should generate it on their machines because of absolute paths used in the bdf file.

All projects are registered in a temporary area known as a workspace. Sharing workspaces is not recommended. Each user must have at least one workspace of his or her own.