Forum Discussion

colinbowern's avatar
colinbowern
Occasional Contributor
13 years ago

VS 2010 Integration - Hard Coded Paths in Test Item (blocking issue)

Each of our developers and testers check out the solution to their own working directory (i.e. I use C:\Projects, others use My Documents\Projects, others use C:\MyApp).  The Team Build Agent (TFS 2010) checks out code to C:\Builds\[Agent#]\[ProjectName]\[BuildDefinition]\Sources. With all of the tools we use that hasn't been a problem because they treat paths as relative to the solution location.  When using TestComplete though I am running into a problem where it appears that it is hard-coding the path in the test item:



<TestComplete_Project_File type="System.String">C:\Projects\MyApp\Unit Tests\SmokeTests\SmokeTests.mds</TestComplete_Project_File>



The problem with this is that this file resides in a different fixed path on the build agent and on other computers.  I tried removing the path to see if it would find the file (which is located in the same folder as the Test Project), but it failed to find it.



At this point this is blocking our adoption of TestComplete in our build process.  How do we get around this?

2 Replies

Sort By
  • JonoW's avatar
    JonoW
    Occasional Contributor
    13 years ago
    We were forced to get around a similar issue, because it's not possible to use relative paths, due to the specifics of the TFS architecture, apparently.



    I received the following reply from SB Support:

    You can try mapping folders, where your files are checked out, as virtual drives using the "subst" command. In this case, you'll be able to use absolute paths to TestComplete projects. E.g. these paths will be "Z:\LocalCopy\TestCompleteProjectSuites\FooTestProject\FooTestProject.pjs" on any machine that is configured in the suggested way.


     


    For additional information on the "subst" command, please see the following articles:


    http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/subst.mspx?mfr=true



    It sort of seems to work - Very much NOT ideal, but at least we can move forward., However, we've now run into another problem of TestExecute trying to access Read-Only Save As dialogs, which don't show up... which then causes the tests to fail.

    The only way around that seems to be to check out the TC stuff before attempting to run the test. But that's no good to us at all.     

  • AlexeyKolosov's avatar
    AlexeyKolosov
    Staff
    13 years ago
    To Colin:


    We will consider changing this behavior. In the meantime, I recommend that you use the workaround mentioned by Jono.






    To Jono:


    If you have not done this yet, could you please create a support case regarding the read-only files problem in TestExecute? You can use our Contact Support form for that.