This topic explains how to set up and run a task-based code review process where you can submit files related to a particular task for code review. It does not matter whether or not these files have been committed to source control. 

Sections include:

Configuration Overview

Configuring a task-driven code review requires:

• Setting up the appropriate preferences on all team Parasoft Test installations as described in General Code Review Configuration.
• Configuring a Code Review Test Configuration on one machine and sharing it across the team as described below.

Configuring a Test Configuration for Task-Driven Code Reviews

When a team member is ready to have the files related to a particular task or set of tasks reviewed, he specifies which tasks (or specific files in the task list) should be reviewed, then runs a task-driven Code Review Test Configuration. This Test Configuration then prepares a review for the appropriate files.

We recommend customizing the built-in Code Review> Task Commit (Assign All) Test Configuration from one SOAtest installation and sharing with the team in order to streamline configuration and updating. 

To customize the built-in Test Configuration: 

1. Open the Test Configurations dialog by choosing Parasoft> Test Configurations or by choosing Test Configurations in the drop-down menu on the Test Using toolbar button.
2. Duplicate the  Code Review> Task Commit (Assign All).

3. In the Scope tab, review the File Filters> Path options settings and adjust them if desired. For details on these Test Configuration settings, see Configuration).

4. If your reporting preferences are not already set to use a unique session tag for code review scans, go to the Common tab, enable Override Session Tag, then choose one of the preconfigured identifiers, or specify your own. This is the tag that will be assigned to all code reviews that stem from this Test Configuration.
   • To ensure proper code review reporting, you must configure a session tag for your code review scans and use that session tag in Project Center to specify which code reviews are associated with particular projects.
5. Customize the Code Review tab settings as desired. If you want the reviews automatically assigned, use the Authors, Reviewers, Monitors, and Filters tabs to define how you want your code reviews assigned. Reviewers and monitors can be assigned to specific authors, or to specific project areas. If you do not specify options here, each author needs to select the appropriate reviewer for each submitted review.
   • In the Authors tab, define the list of developers who are writing code that you want reviewed. For each author, specify an author name and a source control login (if the author’s source control login is different than the author’s name).
     
     • Your list of authors can include all of your developers, or only your junior developers.
     • If the developer who commits a code change is not defined in this tab, the change will be marked as coming from an 'undefined author'.
     • If you don’t want to define every developer, you can 1) enable the Filter tab’s Accept all (also undefined) authors for reviewed paths, and then 2) Use the Reviewers tab to define which reviewers should review different parts of the code.
   • In the Reviewers and Monitors tabs, specify which authors and/or project areas you want each reviewer or monitor to cover.
     • Reviewers examine, comment on, and approve code changes. Monitors supervise the entire process to ensure that revisions are being reviewed and then corrected in a timely manner. They do not need to perform any reviews, but can add comments to the revisions or reviews. This role is optional.
     • Paths are defined in logical (workspace) path convention. Wildcards are allowed. See the "Filter Tips and Examples" box below for more details and examples.
     • You can define reviewers and monitors without mapping them to any particular path or author. Such users will be not assigned to any package automatically, but they will be included in the report and authors will be able to select them in the Code Review Assistant dialog.
6. (Optional) In the Code Review> Filters tab, modify the following options if desired:
   • Ignore changes within suppressed blocks: Enable this option if you want the code review scan to ignore all differences that occur between "codereview-begin-suppress" and "codereview-end-suppress" markers. These are the same markers that are used to prevent the compare editor from displaying differences within specific blocks of code (see Hiding Differences for Specific Pieces of Code for details).
   • Differences: If you want the code review scan to ignore all current source vs. previous source differences that match a certain pattern, specify the appropriate regular expression here. For example, you might use this to prevent any differences in automatically-generated comments from being flagged as requiring code review.
   • Accept all (also undefined) authors for reviewed path: If you don’t want to define every developer, you can 1) enable the Accept all (also undefined) authors for reviewed paths, and then 2) Use the Reviewers tab to define which reviewers should review different parts of the code.
7. Click Apply to commit the new Test Configuration.
8. Share the Test Configuration by right-clicking it, then choosing Upload to Team Server from the shortcut menu.

Submitting Code for Review

A developer or architect can submit code for review as follows:

1. Select the appropriate task node(s) in the Quality Tasks list and run your designated task-driven Code Review Test Configuration.
   
   

2. If you enabled the Show user assistant during scanner run option in the Code Review Preferences panel (strongly recommended), the Code Review assistant will be displayed.
   
   
   
   • You can use this dialog to:
     
     • Provide information about the task you were working on (this code review will then be associated with this task). 
     • You can choose an existing task from the Task list or enter a task name to create a new task. This information is used to determine if you are still working on an existing task, or if you have started a new one. Your changes will be grouped by task in the code review packages that are prepared.
     • Assign a specific reviewer or monitor to the submitted revision when you are submitting a new task for review. This allows you to override the default reviewer/monitor assignment—or to specify a reviewer if one is not already assigned.
     • Provide the reviewer or monitor additional information about the current changes.
     • Indicate the priority of the review.
3. If your Code Review Test Configuration does not have Auto publish reviews enabled, upload the results to Team Server as follows:
   1. After the test has completed, click the Generate Report button that is available in the Test Progress panel’s toolbar.
   2. Complete the Report dialog that opens.

The designated reviewer will then be alerted that code is ready for review. The reviewer can perform the review as described in Reviewers - Reviewing Code Modifications.

After the review is completed, the author can respond as described in Authors - Examining and Responding to Review Comments.

Defining Reviewers, Authors, and Monitors with a Properties File

In addition to specifying code review users directly in the Test Configuration and adding reviewers "on-the-fly" in the Code Review Assistant dialog, you can also define code review users in a .properties file. This can be useful if your review process involves a large number of team members and you can automatically generate a database of your team members.

See Defining Reviewers, Authors, and Monitors with a Properties File for details.