project reference to class library

Progress® Telerik® Test Studio® Feedback Portal

Create an account Log In

Back to Feed

Request a Feature Report a Bug

Completed

Last Updated: 22 Oct 2015 08:29 by ADMIN

Ewin

Created on: 18 Aug 2015 14:01

Type: Bug Report

project reference to class library

With Test Studio, there has been instances where I used a class library so that I could reuse a particular set of code over and over.  

However, with my team grown in size, I need to be able to know that if and when a member of my team picks up a test automation project that it should be able to run with no problems.  

As soon as the member tries to run any test, the test fails to compile properly in Test Studio (I don't think I have seen this issue in Visual Studio so far). So they come ask me what the deal is with the project.  So I direct them to go to the settings  of the project and then script options.  Then I tell them to remove the previous references to the class library dll and add back a reference to the same dll even though the dll did not move in the project.

6 comments

ADMIN

Daniel Djambov

Posted on: 22 Oct 2015 08:29

Telerik: closing issue as unable to reproduce with latest product version R3 2015.

ADMIN

Pavel

Posted on: 01 Sep 2015 12:08

We are unable to reproduce this problem. Could you provide a sample test project using external class library which inhibits the described behavior? You can do so by opening a support ticket. We will try to replicate the issue with one of our internal TFS servers and get back to you with our findings.

Ewin

Posted on: 27 Aug 2015 13:33

@Telerik, I have my projects in TFS to rely on the source control ability.  I committed the class library into its respective folder on tfs. 

When the team member pulls the project down from tfs, the class library is present.

ADMIN

Daniel Djambov

Posted on: 27 Aug 2015 13:09

Telerik: Yes - thank you very much for the details - I figure out the use case. However I'm not able to reproduce it, something is still missing to me - probably the way team members get the project (from tfs or copy it somehow). We actually use relative paths, so in your case the path to the library should be project name\zhelper\class.dll and this is the case right now with the product. If the folder is outside the project, then the relative path Is used again. I tried creating a project with folder and class in it, reference it from Test Studio project settings, then copied the project to another location, but still the code file reference is valid and works fine, so I'm missing something in between.

Ewin

Posted on: 26 Aug 2015 17:13

@Telerik, I have organized my test automation projects to consist of folder called zhelper.  In this zhelper folder, I place all tests that I intend to reuse like a user login to application, tests that performs a navigation to use it across numerous test.  

In this same folder, I put my class library (dll file) there.  So the relative path of my class library should be project name\zhelper\class.dll, but for me, the absolute path is C:\Users\ewin.hong\Desktop\Automation2013\ project name\zhelper\class.dll for example.  But a team member can place the project wherever they like even though I recommend that having a central folder where the project will be on the desktop.  

So far, I recall three separate instances where a different team member (each time) had to do the exact same thing in providing references to the class library I have placed in the zhelper folder.  

This was in response to executing a test list each time giving me the error.  Not at a quick execution I believe.  

Does that clear up anything for you?

ADMIN

Daniel Djambov

Posted on: 26 Aug 2015 15:25

Telerik: Hi Ewin, could you please be more specific on the details around the problem, so we can figure it out better - for what I understand, all team members use the same project, new team member comes, takes the project and tries to run a test, but compilation error is out, so he has to remove the external reference and add it again? Basically external references, that are not in the GAC are added with relative paths to the project root. Which means that if each member gets the project from TFS in a random folder, then he/she will not be able to get the proper path of the external library and will fail. If this is the case, I would recommend having the dll within the project itself, but not in any Test Studio default folder (not in bin. TestLists, Results, Data) so that the path is always same within project or some similar action to ensure same path. If the above is not the problem you describe, please provide more steps for your use case. Thank you, Test Studio team