Pros and cons of using Shared mode

Question

We're not using it right now, but I'm afraid we'd just be changing one set of problems for another. &nbsp;Any recommendations for or against?

tristaanogre · Accepted Answer

AlexKaras wrote:
&nbsp;
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. &nbsp;Shared mode should be viewed as sharing between workstations, NOT sharing between users.&nbsp;
&nbsp;
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
&nbsp;
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". &nbsp;That's what code control repositories are for.... &nbsp;How do I know? Because we attempted shared mode to get around using a code repository and it was an unmitigated disaster. &nbsp;

shankar_r · Answer

Best way to maintaining large project with more number of developers would be as tristaanogre said Source Repository tools like Git, Mercury and etc,.
&nbsp;
In our project what we are doing,
&nbsp;

As we have Data-Driven framework in place, we will create a unit for each Business components in Master branch and one work branch.
Each developer have their own branch created from Master branch
On Weekly basis, I will get all the Name mapping from team member and merge them in my project
Same way for excel test data sheet, merge those sheets in my machine
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]
If there any conflicts we are using KDIFF to solve.&nbsp;http://kdiff3.sourceforge.net/
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.

alexkaras · Answer

I think that above is a fantastic summary from Robert.
&nbsp;
&gt; Shared mode or something else?
Yes, Shared Mode for running tests.
No, something else for *concurrent* development.
&nbsp;
&gt; &nbsp;Locking my project in a vault every night so no checking allowed? &nbsp;
Yes, locking version control is the best choice. (We had this discussion here some time ago.)&nbsp;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 · Answer

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. &nbsp;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. &nbsp;
&nbsp;
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 · Answer

We have Subversion already. &nbsp;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.&nbsp;There's a proposal now that we share our project with another, larger team that is not in our office. &nbsp;They are working on related files but not the same ones. &nbsp;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. &nbsp; Then the question came up about shared mode, so now I'm researching that.&nbsp;Any suggestions? &nbsp;Shared mode or something else? &nbsp;Locking my project in a vault every night so no checking allowed? &nbsp;;)

alexkaras · Answer

Hi Marsha,
&nbsp;
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.
&nbsp;
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.

Forum Discussion

Pros and cons of using Shared mode

8 Replies

Related Content

Shared Steps

Shared Name Mapping file uses absolute path?

Using mocking in SoapUI Pro

SoapUI Pro headless using property file

Shared workspaces

Recent Discussions

Floating window bleep overlapping window takes longer time (~10 min) to click the button on it.

Test case randomly fails with "parent object was not found"

Does TC have a .within() method similar to Cypress.io?

SessionCreator /Timeout option not firing EventControl_OnTimeout

testcomplete feature Intelligent Quality Add Ons