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
The way we always handled it is we kept a copy of the test source local on each tester's hard drive for development and then used a source control process (Mercurial, for example) to make sure everyone's source base was up to date. That way, when we ran our tests, they were run on the server copy that was pulled down rather than on what the testers were running against. Running in shared mode was a hassle for us because we'd always be stepping on each other's files.
Yes, merging NameMapping can be a bit of a PITA, but it worked. What we did to mitigate it a bit is that we mapped only portions of the application under test and then used a lot of FindChild calls to find the controls rather than having to map EVERYTHING.
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.