Forum Discussion

Marsha_R's avatar
Marsha_R
Moderator
8 years ago

Pros and cons of using Shared mode

We're not using it right now, but I'm afraid we'd just be changing one set of problems for another.  Any recommendations for or against?
  • tristaanogre's avatar
    tristaanogre
    8 years ago
    AlexKaras wrote:

     

    But I still very like the possibility to have test project to be located on some shared resource (share) and be used from there from different test machines when running smoke/coverage/etc. tests.

    This above statement I see as a) the primary reason for shared mode and b) a clear description of its best use/practice.  Shared mode should be viewed as sharing between workstations, NOT sharing between users. 

     

    I've used this in the past like this:

    1) Stored my current code/test projects on a shared network hard drive

    2) Opened a copy of TestComplete on my local machine

    3) Opened that shared project and selected shared mode

    4) Made changes to code

    5) Opened a connection to a Virtual Machine

    6) Run TestExecute on that virtual machine

    7) Opened the shared project in TestExecute and selected shared mode

    8) Start a test run on the virtual machine

    9) Continue developing while the test project is running

    10) When test run is complete, I can view the log results on my local machine

    11) Debug code/test errors on local machine

    12) Rerun test on virtual machine without needing to employ source control processes

    13) When code/run/debug cycle is finished, check updated source into source control

     

    If I throw another developer in to use the same shared directory, the steps 4 through 9 get messy... even the test runs get messy because I have no control over what the code is that's being run... code changes may be implemented that I did not intend and, therefore, "blow things up".  That's what code control repositories are for....  How do I know? Because we attempted shared mode to get around using a code repository and it was an unmitigated disaster.  

AlexKaras's avatar
AlexKaras
Champion Level 3
8 years ago

Hi Marsha,

 

As others have already pointed out, shared mode is not the best thing for concurrent development because: a) one will get constant requests to reload units changed by someone else; and b) TestComplete uses the 'last writer wins' policy which means that when you get a prompt to reload data changed externally and concurrently (i.e. when you also changed the same unit), you have two options: either reload unit and lose your changes or do not reload, save your changes later thus effectively overwriting changes made by your colleague.

I think that the last point is something that SmartBear must really pay some attention to to make it possible to review/merge changes in order not to lose any data.

 

What personally I really loved Shared mode for, was their configuration data personalization (https://support.smartbear.com/testcomplete/docs/working-with/teamwork/sharing-projects.html). I am writing about this in the past tense because it looks like this functionality got some flaws in the past versions, but otherwise it was really convenient to: a) set configuration values of project variables and state of test items (on/off) on the per-machine base and do not bother with preserving or constant editing of local configuration files and their committing or exclusion from commit into version control; and b) to have all logs located in the same place and be accessible for comparison/review from TestComplete within the same project. The only disadvantage for the point a) is that it is not possible to edit project variables / test items state using TestExecute.

But I still very like the possibility to have test project to be located on some shared resource (share) and be used from there from different test machines when running smoke/coverage/etc. tests.

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    8 years ago
    AlexKaras wrote:

     

    But I still very like the possibility to have test project to be located on some shared resource (share) and be used from there from different test machines when running smoke/coverage/etc. tests.

    This above statement I see as a) the primary reason for shared mode and b) a clear description of its best use/practice.  Shared mode should be viewed as sharing between workstations, NOT sharing between users. 

     

    I've used this in the past like this:

    1) Stored my current code/test projects on a shared network hard drive

    2) Opened a copy of TestComplete on my local machine

    3) Opened that shared project and selected shared mode

    4) Made changes to code

    5) Opened a connection to a Virtual Machine

    6) Run TestExecute on that virtual machine

    7) Opened the shared project in TestExecute and selected shared mode

    8) Start a test run on the virtual machine

    9) Continue developing while the test project is running

    10) When test run is complete, I can view the log results on my local machine

    11) Debug code/test errors on local machine

    12) Rerun test on virtual machine without needing to employ source control processes

    13) When code/run/debug cycle is finished, check updated source into source control

     

    If I throw another developer in to use the same shared directory, the steps 4 through 9 get messy... even the test runs get messy because I have no control over what the code is that's being run... code changes may be implemented that I did not intend and, therefore, "blow things up".  That's what code control repositories are for....  How do I know? Because we attempted shared mode to get around using a code repository and it was an unmitigated disaster.  

    • AlexKaras's avatar
      AlexKaras
      Champion Level 3
      8 years ago

      I think that above is a fantastic summary from Robert.

       

      > Shared mode or something else?

      Yes, Shared Mode for running tests.

      No, something else for *concurrent* development.

       

      >  Locking my project in a vault every night so no checking allowed?  Smiley Wink

      Yes, locking version control is the best choice. (We had this discussion here some time ago.) Any merge is a risk of uncontrolled conflict. Unfortunately, locking version controls are not popular now and, probably, not working good over intranet and VPN networks...