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...

    • tristaanogre's avatar
      tristaanogre
      Esteemed Contributor
      8 years ago

      I've found that shared mode works best with a team of one or two people or if each person is dedicated to a specific project.  The reason being is that, if you are "sharing" a project and you are both working on it at the same time, as soon as one person saves a change, the other person gets a notification that a file has been changed.  

       

      If you want multiple people to be working on, editing, etc., different files at the same time, a source control repository solution like GIT, Mercurial, or TFS is your better bet.

      • Marsha_R's avatar
        Marsha_R
        Moderator
        8 years ago

        We have Subversion already.  What we have been doing in the small group is periodically merging everyone's project files on one machine and then checking them in from there, rather than everyone checking the whole project in every day.

         

        There's a proposal now that we share our project with another, larger team that is not in our office.  They are working on related files but not the same ones.  I would rather merge the projects when each team is finished, because I feel that limits the risk and makes it easier on both teams.   Then the question came up about shared mode, so now I'm researching that.

         

        Any suggestions?  Shared mode or something else?  Locking my project in a vault every night so no checking allowed?  ;)