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.  

  • 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?  ;)

      • shankar_r's avatar
        shankar_r
        Community Hero
        8 years ago

        Best way to maintaining large project with more number of developers would be as tristaanogre said Source Repository tools like Git, Mercury and etc,.

         

        In our project what we are doing,

         

        1. As we have Data-Driven framework in place, we will create a unit for each Business components in Master branch and one work branch.
        2. Each developer have their own branch created from Master branch
        3. On Weekly basis, I will get all the Name mapping from team member and merge them in my project
        4. Same way for excel test data sheet, merge those sheets in my machine
        5. All developers will commit their code in their own branch and merges with work branch [without committing Name mapping, Test data sheet, *.tcLS,*.tcCfgExtender and *.bak files as I'm committing merged Name mapping and test data from my machine]
        6. If there any conflicts we are using KDIFF to solve. http://kdiff3.sourceforge.net/
        7. Once the scripting completed for the particular release i will merge them with Master.

        This is way we are doing, we will get into some nightmares when more then developer uses same unit but it is better than other ways to handle the large project.