Code Collaborator TestTrack Integration

From Seapine Labs

SmartBear's CodeCollaborator is becoming a popular tool used by developers to do code reviews.

CodeCollaborator offers a way to integrate with Defect tracking tools and the question has been asked if it can be integrated with TestTrack Pro.

This article shows some of the integration you can set up between CodeCollaborator and TestTrack Pro.

Note: This article may not cover every possible way to integrate the two applications.

Contents 1 CodeCollaborator Defects vs. TestTrack Defects 2 The integration 2.1 Link to add defect 2.1.1 SoloSubmit 2.1.2 Add Defect page 2.2 Link to existing defect 2.2.1 Using the record id 2.2.2 Using the defect number 2.3 Regular expression to link to a defect 3 Using the integration 3.1 Adding a Defect 3.2 Track externally 4 Setting up a trigger 4.1 The trigger 4.2 The script 4.2.1 Field Mapping 4.3 Download 4.4 Setup

[edit] CodeCollaborator Defects vs. TestTrack Defects

There seems to be a conceptual difference between defects in CodeCollaborator and TestTrack. TestTrack defects are those that are generally found through the use of an application. They are reported by a customer, a member of the qa team, or a development team member testing out portions of the application. CodeCollaborator defects are generally those found while reviewing the code, so they may have more to do with the logic or other aspects of the code.

One must consider which, if any, CodeCollaborator defects should be also tracked in TestTrack Pro. There isn't one correct answer. The answer depends on your use of both applications and on you company's process.

[edit] The integration

The integration is setup between the CodeCollaborator server and the TestTrack web client.

There are three pieces to this integration:

• Link to add defect

• Link to an existing defect

• Regular expression to link to a defect

The integration is setup using the Site-Wide administration page under "General". Figure 1 below shows the section for bug-tracking integration:

[edit] Link to add defect

[edit] SoloSubmit

The easiest way is to open SoloSubmit. If you point the user to the generic url http://yourwebserver/ttweb/loginsolosubmit, the user may have to choose a project, if you have more than one project using SoloSubmit.

You could pass instead a URL that already includes the id for the project, something like:

 http://yourwebserver/scripts/ttcgi.exe?command=SoloSubmitScreen&databaseid=1 

[edit] Add Defect page

You could set it up so it opens the add defect page on the web client, but you would have to embed the username and password in the URL. This means everyone would use the same username and password to add defects, which would be visible in the URL.

This may be a viable solution if you create a user specifically for this and create a security group for this user whose permissions allow only to add a defect.

For more information on how to build this URL, read this knowledge base article

[edit] Link to existing defect

The easiest solution is to use the http:// link from the TestTrack address bar. You may be able to use the ttstudio:// link, but it will require you to configure the TestTrack URL redirector if you want it to still open the web client. For this example, the http:// link will be used.

[edit] Using the record id

The http url in the TestTrack address bar uses the record id for a defect. This is the "safest" id to use, since it will not change. If the defect is renumbered, a link that uses the record id will not be affected, it will direct you to the same defect.

As indicated in the instructions for CodeCollaborator, we must place BUGID where the number should be placed.

The URL may look something like this:

http://yourwebserver/scripts/ttcgi.exe?command=hyperlink&project=Sample%20Project&table=dfct&recordID=BUGID

[edit] Using the defect number

You can edit the URL so it uses the defect number. Most developers will not know the record id of a record, but they should know the defect number. The only risk is that if the defect is renumbered, it will no longer point the correct defect.

To use the defect number instead of the record id, simply substitute "recordID" with "number".

As indicated in the instructions for CodeCollaborator, we must place BUGID where the number should be placed.

The same URL above now looks like this:

http://yourwebserver/scripts/ttcgi.exe?command=hyperlink&project=Sample%20Project&table=dfct&number=BUGID

[edit] Regular expression to link to a defect

CodeCollaborator allows you to setup a regular expression to link to a defect. It will look for the string specified in the expression and retrieve the number passed with that token. This number is then passed to the link you set up for defect linking.

CodeCollaborator uses the word "case" as an example, and provide this as the reqular expression:

case\s*(\d+)

This example will use the word "ttp:", and the regular expression is:

ttp:\s*(\d+)

Figure 2 below shows the bug-tracking integration window with all three fields filled.

[edit] Using the integration

The integration can be used when you are adding a defect in Code Collaborator, when you mark a defect to be tracked externally, or when you are reviewing a defect.

[edit] Adding a Defect

When adding a defect, insert the token with the corresponding TestTrack defect number.

For example, if you are adding a defect in Code Collaborator and you would like to link it to defect 4 in TestTrack, include the following in the comments:

ttp:4

Figure 3 below shows a sample defect created in CodeCollaborator.

Once the defect is added, we can see that ttp:4 is a hyperlink, and mouse hovering over it, we can see the actual URL, as shows in Figure 4.

[edit] Track externally

Selecting the option to track the defect externally gives you two options:

• Set up a link to an existing defect in TestTrack.
• Add a new defect to TestTrack (no link established).

To set up a link, click on the "[Track Externally]" link for the defect, and then for the "External Name" enter the number, preceded by the token, of course.

Figure 5 below shows the "Externalize Defect" tab with a link established with TestTrack defect #4:

To add a new defect in TestTrack, click on the "create a bug in bug tracker" link. This will open SoluSubmit based on how this was set up by the admin.

Note: The created defect will not be automatically linked in TestTrack. If you don't know the number, you can not add it in the comments section.

However, CodeCollaborator does have Java client classes that allow access to CodeCollaborator programatically. It also has a command line client that allows you to modify records. It may be feasible to have an automation rule in TestTrack launch a Java app or a batch file that would add the link to the defect in CodeCollaborator.

[edit] Setting up a trigger

CodeCollaborator has triggers that could be used to automate the process of creating a defect in TestTrack. Using variable substitution, you can gather data about the review and defect and pass it to TestTrack.

The following example is a trigger that adds a defect to TestTrack with data gathered using variable substitution.

This example will add every CodeCollaborator defect into TestTrack. This is something that may not be desired, as discussed at the beginning of this article.

[edit] The trigger

In the trigger section you have a specific area for defect triggers. While this is advantageous, it is one trigger for any defect action. This means that the trigger will fire if it is an add defect action, an edit defect action, a fix defect action, etc...

There does not appear to be a way to filter which action fired the trigger. This means your script will have to try to figure this out, or at least take it into account.

In the sample script, since its only purpose is to add a defect, it only tries to prevent creating duplicates.

[edit] The script

The sample script is written in C# using Visual Studio 2005, so if you would like to use the .exe you will need to have the .NET framework version 2.0 or higher.

The script takes the following parameters:

• SOAP server URL
• TestTrack project name
• TestTrack username
• TestTrack password
• $defect.text*
• $defect.custom.Severity*
• $defect.custom.Type*
• $defect.custom.Summary*
• $user.name*
• $defect.id*
• $review.id*

*CodeCollaborator variables

One way to minimize the amount of parameters is to store the TestTrack information in a config file or hard code it. There does not appear to be a way to access the CodeCollaborator variables programatically.

[edit] Field Mapping

The script will map the defect severity field in CodeCollaborator and map it to the severity field in TestTrack. The Type field in CodeCollaborator is mapped to the Type field in TestTrack. This script does not check if the values in Code Collaborator exist in TestTrack. If the values do not exist in TestTrack, the add defect operation will fail. This can be addressed by ensuring that both applications have the same values for these fields, or adding a method to the script to check the values for these fields and add them if they are not found.

The Comment field is mapped to the description field and a custom defect field called Summary in CodeCollaborator is added to map it to the summary field in TestTrack.

The script expects the full user name in CodeCollaborator to be in the format FirstName LastName. It then modifies it to be in the format LastName, FirstName when it sets the Entered By field in TestTrack.

The CodeCollaborator defect id and review id are used to build a string in the following format:

<review id>:<defect id>

This value is stored in the TestTrack defect reference field and is used to see if the CodeCollaborator defect already exists in TestTrack to determine if the defect should be created in TestTrack.

[edit] Download

The sampe script is available for download. However, it is provided as an example only. Unless your CodeCollaborator environment and TestTrack project are set up exactly the same, this script will require modifications. Seapine's Professional Services are available if you require a custom solution.

The sample script is available for download here. It includes the Visual Studio 2005 project and the debug built binaries.

[edit] Setup

The trigger setup consists of two text boxes:

• Executable

• Parameters

Executable: Path to the script or executable. A short path without spaces avoids possible issues with lenght of path or spaces. This is not to imply that there are issues, but it does eliminate them in case the script or executable does not appear to run.

In this example, the AddDefect.exe is copied to the root of the c:\ drive, so the path C:\AddDefect.exe is used.

Parameters: Parameters to pass the executable. In this example the following parameters are passed:

"http://localhost/scripts/ttsoapcgi.exe" "Sample Project" "Administrator" "" $defect.text $defect.custom.Severity $defect.custom.Type $defect.custom.Summary $user.name $defect.id $review.id

Figure 6 below illustrates the trigger setup.