| || |
Automate upgrading my Frame File
I am working in Client/Server Application from early stage. Therefore, application frame is keep changing such as its child windows, menus, additional pane, customized tools items..... Even the Executable application name is changing...
Is there any way I can automatically update my frame file or Do I have to re-record my frame file every time it changes?
Re: Automate upgrading my Frame File
I am not aware of any way to update your window decs "automatically" other than re-recording them (which in itself is somewhat "automatic" being that you don't have to write the code yourself).
Given that things are still changing a lot, you can establish some coding practices (standards, conventions) that will make your life easier in regard to the scripts that you are trying to write and maintain. For example:
1. The app name itself changing is an easy one. In all Silk code that you write (functions, methods, testcases) whenever you need to refer to the app name use the global variable wMainWindow instead. If your AUT was NotePad then instead of NotePad.File.Open.Pick () you would use wMainWindow.File.Open.Pick (). Then when your app name changes you just reset the value of wMainWindow in your frame file adn all Silk code will now work again in this regard.
2. Instead of just accepting and using the "identifier" values that Silk "records" into the window dec, as you start using those identifiers in Silk code make sure the window dec has a meaningful identifier that makes your code easily readable. When you re-record the window decs you will have to add a step to adjust the appropriate identifiers to match what's in other Silk code. But that's a LOT easier than the opposite approach of updating all of the Silk code to be the newly recorded identifier. You can minimize the "adjust" effort by addressing only the identifiers that you have started using in your Silk code, rather than all of them.
3. One of the things I have done with my app (for totally different reasons than yours) is that I have a vast majority of all of the fully-qualified identifier names buried inside of common functions and methods, and NOT in my actual testcases. The fully-qualified idetntifers are what will change as your window decs change so my approach is to minimize the amount of editing I will have to do by minimizing the number of places/files that contain fully-qualified identifiers. The only testcases that will have fully-qualified identifiers in them are ones that do actual UI tests (which we avoid right now because we know the UI itself will be changing within the next year or so), and even a lot of those can be extracted from the actual testcase code if you get clever with parameters to your methods and functions. This saved me several times already. About 6 months ago the process to "add a user" changed drastically in my UI. I just updated my fAddAUser function and a few associated methods then all testcases (about 150 of them) that call fAddAUser were back to working as expected.
4. Another "trick" that I use came out of my frustration with fully-qualified identifiers not being all that readable in my Silk code. So if the beginning part is the same in a lot of statements then I define a WINDOW variable named wWin, set it to the part that's repeated a lot, then use wWin in the repetetive statements. For example, if my AUT was NotePad and I was writing a script that worked with the Edit menu a lot then I would decalre "WINDOW wWin = NotePad.Edit" then ever place in this script where I would have NotePad.Edt I use wIn instead. It's a very simple substitution.
Does this all make sense?
[This message has been edited by pcostigan (edited 03-08-2001).]