Quite often, test projects contain computer-specific values and settings. They work properly on the computer where the test project was created or where a test was recorded, but when the tests are run on another workstation, using these values and settings causes your test project to fail to perform certain actions. You may experience these problems if you share the same project among several testers or if you move your project to another workstation. This topic describes the settings and values that may cause problems in these situations and provides some workarounds.
Path to Tested Applications
When you add a tested application to your project, TestComplete stores a relative path to the application, if it is possible (the path is relative to the project). This is possible if the tested executable and the project are located on the same hard drive. However, this is not possible when the application resides on another hard drive or on another computer on the network. In this case, TestComplete stores an absolute path. You can also specify an absolute path in the Tested Applications editor.
Using absolute paths may cause problems if your project is shared among several testers or if you move the project to another computer, because this path may be invalid on other computers. To avoid the problems, use any of the following workarounds:
-
Try using relative paths, if possible, and if you move your project to another location, move your tested application(s) along with the project.
-
If you share the project among several testers, place the tested application(s) in some shared folder and specify the network path to the application when adding this application to your TestComplete project. For instance, in the path \\MyComp\SharedFolder\MyApp1.exe, MyComp is the computer name and the rest is the path to the executable on this computer.
You can change the path in the Tested Applications editor or in scripts by using the Path property of the TestedApp object that provides a scripting interface to your tested application.
Page Address in Web Testing
To obtain scripting access to web pages, you use the Page method of the Window object. This method has a parameter that specifies the address of the desired web page, for instance, http://myserver/folder/mypage.htm. If the tested web page resides on the computer where TestComplete resides, then the parameter may contain localhost instead of the server name: http://localhost/folder/mypage.htm. The localhost value makes your code computer-dependent. If you move the project to another computer, the page’s address will become invalid and you will have to change it in your scripts. To avoid this problem, use the server name instead of localhost when opening pages in your Internet browser. For instance, use http://myserver/folder/mypage.htm instead of http://localhost/folder/mypage.htm.
Issue-Tracking Templates
On the Issue-Tracking Templates page of the project editor you can create issue-tracking templates that will be used to add work items to issue-tracking systems directly from the test log or from script. When creating a template, you specify connection settings for the issue-tracking database to which the template will add work items. After you move the project to another computer, you should open the Issue-Tracking Templates page and re-bind the template to the issue-tracking database.
Database Checkpoints
When creating database checkpoints, you specify the database whose data will be compared. The database connection string may contain computer-specific data. This typically happens in Microsoft Access databases (*.mdb): their connection strings include the database’s file name. This makes the connection strings computer-dependent, because most likely, it will point to an non-existing file if you move the project to another computer, so the checkpoint will not function.
To avoid the problem, use computer-independent settings. For instance, you can move the database file to a shared folder and specify the network path to the database file when creating a checkpoint, for instance, instead of C:\MyProject\MyDatabase.mdb use the string \\MyComputer\SharedFolder\MyDatabase.mdb. In this way, you will not have to change the database checkpoint after you move your project to another workstation.
See Also
Using Test Projects in Shared Mode
Sharing Project Items and Their Child Elements Among Several Projects