Forum Discussion
If you want to place the resources inside the Test Suite or Test Case directory, then append the same after ${projectDir}
Say a data.csv is placed under projectX (Project), suiteY (Test Suite), and kaseZ (Test Case) , then refer it as
${projectDir}/projectx/suiteY/kaseZ/data.csv
Haven't tried for myself, but worth giving it a try.
This works, but only because you are supplying so much of the directory path in the File path field. That kind of defeats the purpose of the original functionality of designating the Resource Root property. When you use ${projectDir} as the Resource Root, at least for regular projects, all you need to enter in the File path field is the name of the file you are looking for, no extra path information is needed. That is most helpful when sharing a project with someone else since ReadyAPI will look in the directory where the project file is stored. All another person needs to do to get tests running correctly on their machine is to have the data source file in the same directory as the project file; ReadyAPI takes care of finding the file in the background. However, it is not so with composite projects, which is a shame because composites are meant to be shared with other people to work on them collectively. Yet, relative lookups don't work correctly.
It would be great if this could be fixed. In the meantime, we have found a workaround that is finally working for us. The local and remote folders have to be named exactly the same. Git renamed the remote to have dashes where there were spaces in the local directory name. In other words, CSBook SWS Build PNR Project (local) was renamed by Git to be CSBook-SWS-Build-PNR-Project (remote). Once I renamed my local to match Git, then we were able to enter something resembling a relative lookup using the following File path value:
CSBook-SWS-Build-PNR-Project/Datasource.xlsx
It's not exactly the same as the Resource Root functionality, but it's working. If the Resource Root functionality could be fixed for composite projects as a low priority, that would be a better solution. Thanks.
- nmrao3 years agoChampion Level 3Good you found the workaround.
Still didn't understand what your approach is ?
You may raise a feature request for the same for your use case.
https://community.smartbear.com/t5/ReadyAPI-Feature-Requests/idb-p/ReadyAPIFeatureRequests- mrugglesaz3 years agoOccasional Contributor
Rao:
I don't understand how this feature request process works. You gave me a link to raise a feature request that takes me back to the same page where I started this thread. I thought that's what I was doing with this request. If you could please submit this request "as is" I'm sure someone who is more familiar with the relative lookup functionality will probably understand the scenario I'm proposing. I would also be happy to take a phone call with one of the engineers to demonstrate what I'm talking about.
Thanks,
Mark Ruggles
Related Content
- 7 years agoJSoul