Commit and Update

After multiple users share the team project, testing will be conducted. During the testing process, changes made on the local PC need to be exported to Team Testing Server or changes from Team Testing Server need to be imported into the local PC. Exporting changes from the local PC to Team Testing Server is referred to as commit, and importing changes from Team Testing Server into the local PC is called update.

Commit

Commit refers to applying the local PC’s work to Team Testing Server. The applied work gets shared with other users. Committing with different revisions between Team Testing Server and the local can revert or overwrite other users’ changes. When committing, the revisions on Team Testing Server and the local must be the same. If the local’s revision is lower than Team Testing Server, an update should be performed before committing.

Users can commit in two ways:

1. After running tests, commit changes along with the test results (auto-commit).
2. Users can manually commit.
   • When users commit manually, they can verify the contents to be committed in the commit dialog.

Update

Update refers to import the work from Team Testing Server to the local PC. During an update, encountering resources to be imported from Team Testing Server that have already been modified locally is termed a conflict. When conflicts arise, they are resolved in the update dialog before updating.

The update process is as follows:

1. Check and update revisions between Team Testing Server and the local.
2. Review resources to be updated in the update dialog. Depending on the resource type, different comparison viewers might be shown the update dialog multiple times.
   • Resources managed in JSON or XML formats, such as project properties or toolchains, can be checked for update content through text comparison.
     
   • Code-based resources like stubs or class code are checked for update content through source code comparison.
     
   • The resources managed by the DB, such as requirement traceability, compare the data in the DB in text format to check for updates.
     
   • For fault injections, the update content is reviewed in a form similar to Fault Injection view.
     
   • For tests, the update content is reviewed in a test editor format.
     
3. Resolving conflicts can be done in two ways:
   • Save as server version
     • Select the (Copy all from server to local) icon to copy the version from Team Testing Server to the local. Copying from Team Testing Server to the local overwrites local changes with Team Testing Server version, and local changes cannot be modified. The (cancel copy) icon can revert the copied version back to its original state.
   • Manually resolve by editing
     • Without copying the version from Team Testing Server, the user directly edits the local version. Referring to the current local and Team Testing Server versions, the user saves the version they’ve edited. When users resolve conflicts manually, they should select the (mark as resolved) icon to indicate the resolution of the conflict for that resource.
4. When all conflicts are resolved, the [OK] button becomes active. Clicking [OK] proceeds with the update.
5. Depending on the type of updated resources, reanalysis might be necessary after the update.
   

During team testing, update notifications are provided to keep the local version up-to-date. Besides update alerts, users are informed of the necessity for an update if Team Testing Server and the local have different revisions when committing.

Modify shared resources

Modifying shared resources like stubs or class codes can alter the results of connected tests. When committing the changed resources, the results of the test in Team Testing Server will be unreliable, and the results of the test connected with those resources will be deleted from Team Testing Server. In such cases, the project’s coverage might decrease.

void func() {
 if( returnNum() == 1 ) {
    /* ... */
 } else {
    /* ... */
    }
}

Creating a stub for returnNum() in the above code and connecting it to a test for void func() can affect coverage based on the return value of returnNum() stub. When modifying shared resources connected to tests, the linked tests should be rerun. Committing modified resources leads to the deletion of execution results of tests connected with those resources from Team Testing Server. Tests with deleted results are managed as ‘need-to-rerun test’. During an update, if there are need-to-rerun tests, they are marked with ! in the [Unit/Integration Test] view. Rerunning need-to-rerun will commit new results and remove the ! marker.
When modifying shared resources and automatically committing after running the connected tests, the executed tests are not managed as need-to-rerun tests since new test results have been committed.

Reference Videos

Here are videos you can refer to regarding commit/update/conflict:

• A video demonstrating the creation of stubs, executing tests for automatic committing, and updating committed stubs from another PC.
  

• This video showcases manual commit after modifying source code and updates via update notifications on another PC.
  

• A video demonstrating the process of modifying user stubs, committing changes, and resolving conflicts arising during updates.