Pros and cons of using Shared mode
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 drive2) 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.
