Forum Discussion

clay's avatar
clay
Contributor
7 years ago

Soliciting advice/best practices for SCM of TestComplete (Desktop) files.

We have a small team of individuals that work on keyword test development within the same TestComplete project.  We are using Git for our source control.  Generally speaking, I think we do a pretty good job of partitioning our work such that we do not step on each other's toes.  However, there are a few TestComplete files where this is unavoidable and we have had many issues with conflict/merge resolution.  The files I am talking about are:  NameMap, Stores files (Regions, Files, Objects, XML), and Project files (sometimes).  In our development environment, each test developer has his/her own copy of the test suite on his/her desktop and checks those files in and out of source control using Git.  We do not share files.

 

When we have a conflict, there does not seem to be a clear set of rules that we can go by.  For example, if I move a region store into a folder and my buddy moves that file into a different folder, one would think that it would be a simple matter of "use theirs" or "use mine".  It is not.  Typically what happens is that TestComplete drops the file pointers from the Regions file and deletes all of the folders, leaving the region files pointers as one long, flat list.

 

In some cases we use a "use theirs and mine" merge.  This works most of the time, however, when it does not, we lose pointers/folders.

 

In the worst cases, TestComplete will decide to completely drop the entire contents of the file and we have to manually reconstruct the contents (e.g., go back to a previous version and roll forward our changes). 

 

All of these things have a large cost in overhead that we would love to figure out how to overcome.

 

I see reference material that explains the mechanics of the source control operations using the plugins, but very little guidance on the thought processes and implications of various merge/conflict resolution strategies.  What are your experiences and how do you develop a robust strategy?

 

Thanks.

 

 

4 Replies

Sort By
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    7 years ago

    A couple of strategies for managing NameMapping came up at the recent connect conference.

     

    1) Have one person designated as the "Master of all NameMapping". Anything that needs to be mapped, they map.  They do the mapping ahead of time before automation against the components is started.  Then all automation developers download the latest mapping file before working on that piece of the application under test.

    2) Have one person in charge of "merging" NameMapping.   No NameMapping is actually checked in to your SCM from the individuals.  Instead, they do their mapping and then send their NameMapping.tcNM files to another party.  That person then has a special project in TestComplete whose sole purpose is to use the built in TestComplete "Merge" feature to merge those individual namemapping files into the central one, resolve all conflicts, and then check in to SCM.  Then, once the merging is complete (sounds like a bad sci-fi trope...), the individuals download the latest NameMapping.  I believe Marsha_R uses this method.

     

    As for the other files within Regions, Files, Objects, XML, the way we handle that here is that we a) don't put stores files in different directories.  We just store them in the default project folder structure and use a naming convention to describe what the files are. And b), no two people are working on the same file at the same time.  This is a bit harder to control "automatically", but generally it's a matter of making sure that if I am working with XMLFile1, no one else is at the same time.  That way there is no conflict and we don't have to worry about it.  This might not work for you, depending upon how you structure things.

    • clay's avatar
      clay
      Contributor
      7 years ago

      I like the idea of a "Master of Name Mapping" role.  I am not sure that it would work well in our particular circumstance (because that role would probably fall upon me and I would become the bottleneck :-) ), but it makes a lot of sense in general.  As an alternative, I do the reviews of all the team members' work.  At that time I go through all the name mapping changes with a fined-toothed comb. That seems to take up less time and allows for more concurrency of development by the team.

       

      The biggest problems we have are with the Regions.tcRegions, Objects.tcObjects, and Files.tcFiles directory files rather than the stores files themselves.  Everybody is hitting the directory files (not sure what else to call them) all of the time.  We use folders within the directory files to organize our work.  It seems to have the added benefit of partitioning off groups of file pointers within the XML such that we do not modify the same sub-elements at the same time within the XML.  This helps to avoid a lot of conflicts.  But when we do have conflicts, the traditional resolution strategies ("use theirs", "use mine", "use neither", "mine first, then theirs", "theirs first, then mine"...) don't seem to work very well.  I think it may have to do with the way TestComplete generates UID's in the XML.  My theory is that TestComplete does not do a good job of keeping the UID around when an element position changes within the document.  For some reason, new UID's are assigned and then the mess begins.  For example, in a "keep mine" resolution, I may be discarding a newly assigned UID and keeping the old UID and basically making my element an orphan within the system.

       

      Thanks for the thoughts.

      • tristaanogre's avatar
        tristaanogre
        Esteemed Contributor
        7 years ago

        Yeah, the flat XML structure of the files, including how NameMapping is constructed, is a general problem with source control.  What I usually do, if there's a conflict, is manually merge them.  That's really the only way to control some of it.