Forum Discussion

william_roe's avatar
william_roe
Super Contributor
10 years ago

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 editing the spreadsheet while the test was running but this wasn't the case. We bailed and started working locally which comes with it's own set of challenges. How are others dealing with this or are were we doing something wrong? What happens when a test is changed from the workstation while the test is running on the server? The whole name mapping merges issues are too much to deal with.

7 Replies

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor

    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.

    • william_roe's avatar
      william_roe
      Super Contributor

      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.

       

       

      • tristaanogre's avatar
        tristaanogre
        Esteemed Contributor

        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. :)