cancel
Showing results for 
Search instead for 
Did you mean: 

Add an existing item wholly to project?

SOLVED
chrisb
Regular Contributor

Add an existing item wholly to project?

Hi,



I would like to be able to import a script wholly from one project to another within a project suite but it seems that TC creates a reference to the script in its original location, in effect it is sharing the item between projects. This works great when we want to share a script between projects but what if I want to move a script wholly from one project to another? Am I missing something? Is my desired workflow odd or did SmartBear just not consider this workflow?



Any suggestions on how to import an existing script wholly into a project... other than creating an empty script file and performing some cut and paste! Thanks.





1 ACCEPTED SOLUTION

Accepted Solutions
Ryan_Moran
Valued Contributor

RE: Add an existing item wholly to project?

Technically speaking this is bad practice to copy existing functions/scripts and use them in different projects. It's good practice to encapsulate by using the same script and likely why the add script works the way it does. That said you can copy the SJ file from your Project>Script folder, give it a different name, then add it using the Add Existing option you mentioned. Or simply copy all the code into a new script. 🙂



(Can also right click Save As and save it into a different script)

''-Praise the sun and Give Kudos.''

View solution in original post

11 REPLIES 11
Ryan_Moran
Valued Contributor

RE: Add an existing item wholly to project?

Technically speaking this is bad practice to copy existing functions/scripts and use them in different projects. It's good practice to encapsulate by using the same script and likely why the add script works the way it does. That said you can copy the SJ file from your Project>Script folder, give it a different name, then add it using the Add Existing option you mentioned. Or simply copy all the code into a new script. 🙂



(Can also right click Save As and save it into a different script)

''-Praise the sun and Give Kudos.''

View solution in original post

chrisb
Regular Contributor

RE: Add an existing item wholly to project?

@Ryan, thanks for the quick reply. I should have added some context to my post. This is for the purpose of having a project that can be used by different people to develop their test scripts. We can't do it within our main project because we are using TC source control integration and having a file in a project that only exists locally stops Test Execute from launching when triggered by a scheduled test run in QA Complete. I dont think TE can be configured to ignore the warning message and continue the test run. Maybe its possible to ignore the message by launching TE from the command line but that doesn't help for test runs triggered by QA Complete.

Thanks for the tip on changing the file name,
Ryan_Moran
Valued Contributor

RE: Add an existing item wholly to project?

Makes sense. Not familiar with the tools mentioned. I guess I'm lucky that I'm the only person here that handles the automated testing. Hopefully I at least pointed you in the right direction in regards to what you were trying to accomplish.

''-Praise the sun and Give Kudos.''
tristaanogre
Community Hero

RE: Add an existing item wholly to project?

Actually, I'll have to say, "Au Contrare" in your suggestion to nix "sharing" script files between projects.  If you think about it, if there are two applications under development in a company, both of which need objects to be able to retrieve SQL queries as Record Sets, it's BAD practice to create two different objects in code that do EXACTLY the same thing because it creates a maintenance problem... you update one, you need to make sure you update the other.



In a previous life, we had a set of code that was "Common" to all our automation projects.  That way, rather than needing to copy a unit of code, we just did an "add existing".  Now, this code was "generic" enough... things like I mentioned above where we needed to create objects and such that were in common use...  And, by having all projects point to the same actual code unit and folder, if it got updated (like a bug got fixed) it was fixed in all projects immediately.



Basically, when you get down to it, maintaining a robust test automation suite needs to use MANY of the same techniques as you do in maintaining a robust and mature application's code base.

Robert Martin
[Hall of Fame]
Please consider giving a Kudo if I write good stuff
----

Why automate?  I do automated testing because there's only so much a human being can do and remain healthy.  Sleep is a requirement.  So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.

Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available
chrisb
Regular Contributor

RE: Add an existing item wholly to project?

@robert Agreed in the context of test development you described. As I mentioned to Ryan in my previous reply I should have added some context to my original post. The issue is that we have multiple testers writing tests in our project which is using the source contol integration which is fine and dandy up to this point.

Rather than pollute the working test code with scripts that are under development we create them locally by switching off the option to automatically bind new project items to source control. Unfortunately the workflow in Test Complete forces you to check out the project element 'Script' which in turn creates a reference to the script file. This now causes a missing file warning message any time another testing opens the project. Again, up until this point everything is fine.

We then schedule our tests to run using Test Execute. Test Execute quits the test run immediately upon the warning message being displayed! Note: this has nothing to do with whether warning messages are enabled or not in project settings.

This got me thinking about a work around where testers could develop scripts in a completely seperate project within the suite thus not polluting the good test code in the main project and avoding the issue of missing files when trying to execute a run with Test Execute. The problem with this is that we cannot wholly imported a finished test script into the main project using any features in Test Complete IDE, we can only share the script. This means we now have the script forever in 2 projects or hack our way around it by renaming and moving files. Note that hacking this causes more grief as the project is under source control. 



So, the real problem and the question I probably should have asked originally is 'How can we create a file locally inside a project that is under Source Control without Test Complete forcing us to check out the 'Script' element and add a reference to the file to the project?' If we cant then why on earth does Test Complete give us the option to choose to switch off automatic binding of new project files to the source control?



Any suggestions on how to use the source control integration in Test Complete and have multiple testers develop scripts within a project would be welcome! Note, because TC compiles all the scripts in the project we cant have testers adding half finished or tests with issues in them in the project. I did consider that option, as undesirable as it is.
chrisb
Regular Contributor

RE: Add an existing item wholly to project?

@robert, where did I suggest that SB 'nix' sharing of project scripts?
tristaanogre
Community Hero

RE: Add an existing item wholly to project?

Honestly, in other environments, I did not use the integrated source control.   It depended too much on TC being "smart" in knowing what to check in and check out.



Now, that SAID...  what you can do is give each test developer their own "branch" of the code to check in and out of... and then, outside of TestComplete, merge "completed" scripts into the main code branch for actual test execution once they are completed.  It's how my company uses TFS, actually, for their main application code... 



In my previous life, we used HG Tortoise for our source control which did not integrate directly with TestComplete... but we still, essentially, did the same thing... it allowed multiple test developers to maintain their own branches of code which they were able to keep running without being polluted by other testers... and then, at the end, we merged into the main code once it was approved, reviewed, etc.   Perhaps this will be a good model to follow?

Robert Martin
[Hall of Fame]
Please consider giving a Kudo if I write good stuff
----

Why automate?  I do automated testing because there's only so much a human being can do and remain healthy.  Sleep is a requirement.  So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.

Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available
tristaanogre
Community Hero

RE: Add an existing item wholly to project?

Hrm... my bad... misunderstood... sorry...

Robert Martin
[Hall of Fame]
Please consider giving a Kudo if I write good stuff
----

Why automate?  I do automated testing because there's only so much a human being can do and remain healthy.  Sleep is a requirement.  So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.

Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available
chrisb
Regular Contributor

RE: Add an existing item wholly to project?

@robert Thanks. When I started the project my original thought was to put the whole project under source control in Git and branch as suggested. However, it turns out that TC IDE supports the same source control product that is used by the development team. So that seemed the logical way to go.

I think it might be time to revisit branching. Did you come accross many merge conflicts when merging in scrips and the assocaited changes to .mds files, Script element etc.?
New Here?
Join us and watch the welcome video:
Announcements
Top Kudoed Authors