Shared project and distributed testing

Hi Mark,



While it is usually OK to execute tests on different machines using the same project opened in a networked mode (exactly like you do), I would strongly recommend not to use concurrent development.

According to my experience (and the topic recommended by Tanya basically says the same), the best way to organize the development is like this (general principle - only one person is responsible for the given project item):

a) Consider creation of the common reusable code and move this code into one or more script units. Assign a dedicated person (usually - the most experienced TestComplete user) who will implement code changes into this reusable library. There may be more than one such dedicated person if your project contains more than one library code unit, but in this case they must have their own library code units assigned;

b) This dedicated person is also responsible for making changes in the NameMapping by requests from other team members. Also this person is responsible for integration of all tests created by other team members and for verification that integrated tests still work and do not interfere with one another. Also, during tests integration, this person should analyse test code and move reusable parts into common library;

c) All other team members should use their own local copies of the test project and modify only module(s) they are responsible for. After the developer test code is provided to the person mentioned in paragraphs a) and b), the given test member should synchronize his local copy with the master one from the network.



Summarizing: every team member changes only the code module(s) he is responsible for and do this on his local copy. All code merging, like the changes required to be done for other project items (e.g. changes in the NameMapping, changes to the test items, project variables, etc.) must be done manually by the dedicated person. Then the changed project should be delivered back to the machines of team members.

"All code merging, like the changes required to be done for other project items (e.g. changes in the NameMapping, changes to the test items, project variables, etc.) must be done manually by the dedicated person."



That is the part I am trying to avoid. Seems difficult to manage.

> That is the part I am trying to avoid. Seems difficult to manage.

Yes, this is clear...

Unfortunately, due to the internal structure of all TestComplete items (when properties and their values are linked via unique identifiers) except script units (that are plain text files) I can hardly imagine how their changes can be merged.

(To say the truth, I never saw successful automatic merging even for text files with code except for the simplest cases, but this is another story... :) )