If I add a testcase to my favorites, then I can easily insert a call to run it by right clicking. Why can't I do this for testcases that aren't in favorites?
I'd also like the ability to right click on anything and have a menu item to put its path into the clipboard, so I can paste it elsewhere.
Actually, the second would be better than the first, and would negate the need for the first one.
In iTest 3.3, there is a very nice new ability to insert call steps from inside the test case editor itself. When you choose "call" in the action column, you'll see an ellipsis button ("...") in the right side of the Description column. When you click on it, you'll see a dialog pop up listing all registered procedure libraries and the procedures in those libraries. And it also shows you all of the arguments for the selected procedure so that you can fill in those that you want.
In the cell editor itself (back in the test case editor), you can also use command completion as a faster way of accomplishing this.
Note that to take advantage of this new functionality, you need to go to your test cases containing reusable procedures. You need to use a new checkbox on the General page indicating that this test case contains reusable procedures. And for the procedures in this test case, you need to go to those that you want to make visible, and check a new box in its properties as well. At the same time, you probably want to update the properties for those procedures to document them and their arguments to help the users who may want to use these.
Having said all of that, I agree that it would be nice if you could expand a test case in iTest Explorer and see its procedures as well. We haven't implemented that -- for a few reasons that won't matter to you. Nevertheless, it is a very reasonable feature request. Your other request to grab the URI for the selected file would also be a nice addition as well.
I had noticed the "hit control+space to see the procedures", but it came up empty.
If I click re-usable, does that register that test case as a procedure library, or is that a separate step?
Back in 3.0, there was no benefit to having procedure libraries, and--in fact--rebuilding time made them somewhat unattractive. Even now, having a bunch of procedures in a file makes that file difficult to edit, just from the space-on-screen perspective. And procedures weren't automatically alphabetized, like they were in SVT. Finally, merging a really big XML file can sometimes be difficult. Given all that, I broke up our big procedure libraries into individual test cases.
Given the new features in 3.3, I'm thinking that I might need to revisit that decision. (sigh)
I'm not complaining (ok, I am, but not much): The new features are good. It's just more decisions to juggle.
There is a whole new builder coming in the next release of iTest. This builder is smart about inter-document and inter-project dependencies. It will ensure that only those files that need to be rebuilt (based on the change that was actually made) are rebuilt. This is designed specifically for your scenario -- where you have a few procedure libraries that are referenced by large numbers of other documents. Starting with the next release, unless you make a change that actually would affect other dependent documents, they won't have to be rebuilt. This results in a major performance improvement for most cases. It won't speed up a full clean rebuild. But it will make almost everything else nearly instantaneous.
Regarding your question on reusable procedures, note that there are two different settings. One is on the overall test case -- to indicate whether it should be considered a procedure library or not. If you don't check that property, the procedures in that test case won't be considered regardless of procedure properties. Then each procedure in that test case has a checkbox for it. (This allows the procedure library to have both "public" and "private" procedure declarations.) Once you do this, you should start seeing the nice completions you want when editing test cases. (If not, let us know.)
