File Locks in Shared Mode
When we first started using TC in Shared Mode we ran into conflicts with the Excel File becoming locked when someone else was running a test. I could see how it would be a problem if someone was edit...
Forum Discussion
We use Team Foundation Server and unfortunately the way in which SmartBear integrates does not allow us to associate the changesets with a task via the IDE. We could manually check in and out but more PITA. Sounds as though the Shared Mode doesn't solve anything. Hmmm
Thanks for the reply.
Well, I wouldn't worry about tasks or anything. It's going to take a bit more in the way of communication ("Hey, I'm checking something in!"). In any case, best practice is to not run your tests on the same set of files as you are developing on. Your regular test runs should have a copy of your test projects that are only updated one way (TFS -> Test environment) rather than actually developing against your test environment. Consider what would happen if a developer was developing a web application on your live server that folks were actually using in real time... yeah, not a good practice there. :)
tristaanogre wrote:Well, I wouldn't worry about tasks or anything. It's going to take a bit more in the way of communication ("Hey, I'm checking something in!"). In any case, best practice is to not run your tests on the same set of files as you are developing on. Your regular test runs should have a copy of your test projects that are only updated one way (TFS -> Test environment) rather than actually developing against your test environment. Consider what would happen if a developer was developing a web application on your live server that folks were actually using in real time... yeah, not a good practice there. :)
I don't understand the purpose of shared mode then. Thanks for the feedback.
Shared mode is OK for sharing files among test developers. It still takes some co-ordination to make sure you're not blowing away each other's edits on files and such. However, even with shared mode, I would not recommend running your live tests using the same set of files as you're developing on. IMO, developing automated tests should be subject to the same source control and change control procedures as developing any piece of software.
tristaanogre wrote:Shared mode is OK for sharing files among test developers. It still takes some co-ordination to make sure you're not blowing away each other's edits on files and such. However, even with shared mode, I would not recommend running your live tests using the same set of files as you're developing on. IMO, developing automated tests should be subject to the same source control and change control procedures as developing any piece of software.
Thanks for the feedback tristaanogre
Hi William,
> I don't understand the purpose of shared mode then.
I used to use the shared mode to have the values of project variables and test items state personalized on the per-machine base. In general, this was very handy because it allowed, for example, to connect to server A when test project is opened from machine1 and connect to server B when the same project is opened from machine2 without the necessity to write even a line of code.
The only problem that I had with this was that it was not possible to set the values of the project variables/test items when test project is opened in TestExecute, so I had to either edit then via TestComplete or via direct project file corrections.
The case here is that this functionality seems to be dismissed in later versions of TestComplete for some reason and, while the Support case should exist, I am not sure if and when it will be fixed.
Besides the 'static' settings through project variables and test items, I also found it to be pretty convenient to share data between tests through the temporary project variables. Again, with the project opened in the shared mode, temporary project variables can keep different values when test code is executed from different computers and again, without the necessity to write any single line of code.
Unfortunately, the problem here is that TestComplete separates the values of the project variables on the 'per-machine' base without distinguishing user names. The result of this is that the value of the project variable can be overwritten when the project is opened on the same terminal server computer by different users in different sessions.
This is something that I really love to be improved by SmartBear.
As for your initial question:
I used to use native ADO objects (connection and the recordset) opened with the SHARE_DENY_NONE option in the connection string. This option prevents file locking and makes it possible to query the same file concurrently.
