Add an existing item wholly to project?

It's been a bit since I've done those merges.  The Script.tcScript worked pretty well, IIRC... MDS didn't play quite so nicely with some of the merges.  I would suggest do not, EVER, depend upon auto-merge, no matter what tool you use.  



Script files themselves play nicely...  anything that's the XML file structure of TC project files, just spend good time in examination before merge so you don't inadvertantly mess things up... It does get tricky.



One thing that we did do is make updates to MDS, Script.tcSCript files and other project files "gated" through an integration person.  Rather than having all sorts of folks updating those files all over the place, it just made things so much easier to just handle it centrally.

@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,

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.

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

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

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?

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

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.?