Use approvals to enforce test driven development, code reviews and integration testing in Rational Team Concert
What is Test Driven Development?
Test-driven development (TDD) is a software development process that requires the developer to write an (initially failing) automated test case for the desired functionality, then add the minimum code required to pass the test case and finally refactor the code and ensure the automated tests still pass.
Adding TDD to the project process puts the focus on development through testing the requirements. In traditional development, code is written and then test cases are developed to test the code. In TDD, test cases to satisfy the requirement (generally called unit tests) are written before the implementation is begun.
What are code reviews?
Code review is systematic examination (often known as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers' skills.
This is a very important code quality practice that is often lacking in practice as formal code reviews have required a considerable investment in preparation for the review event and execution time. Here I describe how the review effort (code review metric) can be set up as part of project process to gain insight into what the gain is compared to the investment.
What is integration testing?
Integration testing, sometimes called Integration and Testing and abbreviated as I&T, is the phase in software testing in which individual software modules are combined and tested as a group. It is implemented to verify functional, performance, and reliability requirements after unit testing is complete.
This article describes how to get your project process set up to implement these processes effectively using an IBM® Rational Team Concert™ scrum template. In this article I describe the customizations done in our project process and how Rational Team Concert processes are used to enforce TDD, code review, and integration testing in the development process.
Typical software development project process
A typical project process workflow using Rational solutions can be described as:
- Product requirements are split into development tasks and captured in Rational Team Concert work items. The work items are assigned to developers by the manager.
- Testers develop test cases for these requirements in Rational Quality Manager. These test cases are linked to the work items via the Development Items section for traceability links.
- Developers capture all implementation details and work artifacts in the Rational Team Concert work items.
- The approval process in Rational Team Concert is used to ensure that TDD is enforced in the development process, i.e. test cases are developed before the implementation begins.
- The code review process is tightly integrated in the project process for quality management purposes. The review process in Rational Team Concert is used to ensure that this code quality practice is enforced in the project via the creation of review records for every change set. The work item cannot be resolved unless code review records are approved.
- The integration testing completes the development cycle. Rational Team Concert verification records are used to enforce the integration testing process in the project. Work items cannot be closed until the verification records are approved.
The next section, Project area customization, details the customizations done in the Rational Team Concert scrum template to enforce the above process.
Project area customization
Here we use a Rational Team Concert scrum template to define the project process. Following are the project area customizations done to add TDD and the review process to the default scrum process. New work item attributes are defined.
- Ensures test case development before beginning the actual
implementation. This attribute is an enumeration with values 'Not
Done', 'In Progress', 'Completed' and 'Not Required'. The values
indicate test case development status. These values can be customized
as per project needs.
- Review Effort
- 'Time Duration' is used to track the effort spent in reviews. This is
a useful metric to track whether the project is really gaining from
quality reviews. We have seen drastic reduction in defect leakage from
development to integration testing once the review process was
enforced in the project.
Create the TDD enumeration and add attributes
- Go to Project Configuration > Configuration Data > Work Items > Enumerations in the Project Area: Process Configuration tab.
- Add a new Enumeration ID for the TDD along with defining the literals it can contain as shown in Figure 1.
Figure 1: Define TDD Enumeration
Figure 2: Define TDD Enumeration literals
Now add the new work item attributes to the work item types.
- Go to Project Configuration > Configuration Data > Work Items > Types and Attributes in the Project Area: Process Configuration tab.
- Select the work item type for which these attributes need to be defined. In our case these would be defined for Defect and Task. In the Attributes section, select Add to create the new custom attributes Review Effort with the type of Duration and TDD with the type of TDD (Enumeration) as shown in Figures 3 and 4.
Figure 5 shows the new attributes in the Attributes list.
Figure 3: Add Review Effort in Work Item custom attributes
Figure 4: Add TDD in Work Item custom attributes
Figure 5: TDD and Review Effort in Work Item custom attributes
TDD process implementation
The project requirements are broken into development tasks for which corresponding work items are created in the project area.
- The project manager assigns the work item to the developer.
- The developer initiates the test development with the testing team when beginning the development work. This is done by creating an approval record for TDD (i.e. test cases development) and adding the tester as the approver.
- The tester receives email notification from Rational Team Concert on the approval creation.
- The tester identifies the test cases and scenarios in Rational Quality Manager to ensure testing coverage of the requirements detailed in the work item and links these test cases to the work item in the Development Items section.
- The tester changes the TDD attribute value in the work item to 'In Progress' to reflect the test case development progress.
- Once all the test cases are identified and reviewed with the developer, the tester changes the TDD attribute value to 'Completed' and approves the TDD Approval record. Setting the precondition for Require Work Item Approval on Deliver (client) from the Source Control operation ensures that any change set for the work item can only be delivered when the TDD Approval record is approved. This enforces TDD before any code changes are allowed. .
Figure 6: Precondition to enforce TDD approval process
Code review process implementation
- The developer completes the development based on the work item inputs in the form of requirements and test cases.
- The developer executes the test cases identified in Rational Quality Manager as part of functional verification tests.
- Once the implementation and testing is complete, the developer attaches the code change sets to the work item.
- The developer initiates the review process.
Code delivery is done only after the code review.
- As part of the review process the developer creates an approval of Review type for the change set that needs to be reviewed, with the approver set to the person who should review the changes.
- The reviewer is notified of the review request via an e-mail or an event in his/her event feed.
- The reviewer goes to the work item and looks at the change sets in the Change Explorer view. Sometimes the reviewer will accept the change sets into his workspace so he/she can have a closer look, but looking at them in the change explorer is usually good enough.
- The reviewer adds any comments from the review to the work item and approves or rejects the approval.
- The developer reviews any comments and restarts the process until the reviewer and developer are in agreement on the code changes.
- When the review record is approved, the developer delivers the changes for integration testing.
Setting the precondition for Required Approvals on Save Work Item (server) from the Work Items operation ensures that work items can be resolved only when the Review is approved. If the work item is reopened, a new approval of the Review type is created in the pending state. This ensures that any further code changes are also reviewed.
Figure 7: Precondition to enforce code review approval process
Integration testing process
After delivering the changes, the developer creates a new approval of Verification type in the pending state and assigns it to the tester when resolving the work item. The verification process completes the integration testing process.
The work item is closed only when the Verification is approved. This is achieved by setting a precondition for Required Approvals on Save Work Item (server) from the Work Items operation.
Figure 8: Precondition to enforce integration testing process
The process customizations required to effectively implement TDD with code quality and integration testing in the project are now complete.
- More about Rational Team Concert:
- Download Rational Team Concert from Jazz.net.
- Evaluate IBM software.