Git review for TestComplete projects

Teams using TestComplete face a common problem: one small test change can produce a wide set of modified files, and not all of them deserve the same level of scrutiny. The fix is not to review everything equally – it is to classify TestComplete artifacts by risk, then standardize how your team reviews, stages, and merges them. This article outlines this process and offers best practices for using Git effectively with TestComplete projects.

How to use Git effectively with TestComplete

TestComplete supports Git through its Git plugin and uses the Git command-line utility, with source-control actions available from the Project Explorer context menu, the File > Source Control menu, and the Source Control toolbar.

The best practice you should follow is to separate test logic from tooling noise. In a typical TestComplete project, the files that most directly express automation behavior are script source files, keyword-test bodies, and a few project-definition files. Your uploaded TestComplete format references show that script units are plain text in the configured language, .tcKDTest files contain the actual keyword operations and control flow, .mds describes project items and execution-related structure, and .tcTAs stores tested application definitions. Those are the files where meaningful behavior changes usually live. Here’s how to approach this:

Step 1: Review the files that change behavior first

Start every review by looking at the files that can alter what the test suite does. In practice, that means script files such as .js, .py, .vbs, .sds, or .scs, then individual keyword test files (.tcKDTest), then project-level control files like .mds and .tcTAs. This order matters because it surfaces intent first: what logic changed, what test path changed, and what environment or app definition changed. GitHub’s pull request guidance recommends small, focused changes and explicitly suggests guiding reviewers on the order in which to review files when multiple files are involved.

Step 2: Treat structural files as quick-review items, not deep-review items

Some TestComplete files matter, but usually only at the “confirm the structure matches the intent” level. Good examples are .pjs, .tcKDT, and .tcScript. These files commonly reflect that a project, keyword test, or script unit was added, removed, or renamed. They are worth checking, but they generally do not deserve the same attention as the test logic itself unless the change was explicitly about suite composition or execution structure. Reviewing one file at a time, and marking files as viewed as you go, is a solid way to keep this process disciplined.

Step 3: Isolate Name-Mapping changes

Name Mapping deserves special handling. Your uploaded agent setup guide explicitly says Name-Mapping files are binary and should not be git merged, and SmartBear’s Name Mapping documentation confirms that the repository stores aliases, hierarchy position, identification criteria, and optional images for tested objects. That makes Name Mapping important, but often poor for line-by-line merge review. The right practice is to keep mapping changes isolated in their own commits or pull requests whenever possible, so reviewers know they are evaluating object-recognition updates rather than test logic.

Step 4: Create a “default staging policy”

A disciplined staging policy will save more time than any clever merge trick. The simplest workable policy is this: Review and stage script files and .tcKDTest files first. Then quickly inspect .mds, .tcKDT, .tcScript, and .tcTAs to confirm the structural changes are expected. Only stage .tcNM when the task intentionally involved Name Mapping. Only stage stores, variables, or image related assets when test data, variables, checkpoints, or baselines were deliberately changed. This turns an overwhelming change list into a repeatable checklist grounded in file purpose rather than file count.

Step 5: Keep pull requests small and single purpose

This is standard Git hygiene, but it matters more in TestComplete because tool-driven file churn can obscure the real change. GitHub recommends small, focused pull requests with a clear purpose and enough context for reviewers to understand what changed and why. For TestComplete work, that means avoiding mixed pull requests such as “refactored scripts + updated Name Mapping + refreshed baselines + added test data” unless those changes are inseparable. The cleaner pattern is one pull request for behavior, one for mappings, and one for supporting assets if needed.

Step 6: Use .gitattributes to reduce noise

Git’s attributes system is built for exactly this kind of repository tuning. The official Git documentation notes that attributes can be used to tell Git which files are binary, how to diff nontext files, and how to apply path specific handling. That makes .gitattributes a strong fit for TestComplete repositories: treat clearly diffable text artifacts as text, and mark files like Name Mapping or other opaque/generated assets as binary or nomerge where appropriate. Git also supports custom diff drivers and custom merge drivers when you need more control. A practical result looks like this in policy terms: script files and XML-like project files get normal review-friendly diffs, while opaque or generated assets get reduced merge expectations. That will not remove all noise, but it sharply reduces the chance that reviewers waste time on files that are not realistically reviewable.

Step 7: Give reviewers a file order

When a pull request includes multiple TestComplete artifact types, tell reviewers where to start. GitHub explicitly recommends giving guidance about review order when a change spans multiple files. In a TestComplete repository, the best sequence is usually: script files and .tcKDTest first, then .mds and .tcTAs, then indexes like .tcKDT and .tcScript, then data or mapping artifacts only if they were part of the intended change. That turns review from “scan a long list of changed files” into “verify behavior, then verify structure, then verify support artifacts.”

Step 8: Do not rely on the IDE alone for judgment

TestComplete’s Git integration is useful, but its main value is operational convenience: enabling the Git plugin, pointing TestComplete at git.exe, and using built-in source-control commands from the IDE. That does not replace a repository strategy. Teams still need external Git discipline around staging, pull request scope, file classification, and merge behavior. TestComplete gives you integration points; Git best practices still determine whether the repository remains understandable.

Unlocking the benefit of Git and TestComplete together

Using Git effectively with TestComplete projects comes down to treating different file types according to their real risk. Scripts, keyword tests, and project-definition files should get the deepest review because they change behavior directly. Structural files should be verified for consistency. Name Mapping, however, should be treated as shared infrastructure: too important to ignore, but too fragile to review like ordinary text code. The goal is not to merge it cleverly, but to minimize simultaneous edits, isolate .tcNM changes, make them explicit in pull requests, and validate the affected tests immediately afterward. Teams that follow that discipline will get the real benefit of Git in TestComplete projects: clearer reviews, safer merges, and far less time wasted on noisy or misleading file changes.