SPONSORS:






User Tag List

Results 1 to 3 of 3
  1. #1
    Junior Member
    Join Date
    Mar 2002
    Location
    Concord, NH, USA
    Posts
    11
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Testing Java Applications

    I am testing Java installers and uninstallers creted by InstallShield. These Java applications display unique panels with the same names. I have done a bit of floundering in an effort to run these applications from SilkTest with little success. I have a need to uniquely reference the windows. This problem becomes worse because several of .inc files for various installers will be in scope at the same time because the test scripts contain multiple tests that use various installers and uninstallers.

    I have a couple of areas of uncertainty.

    First, should I use the default Record Window Declarations Options? Will I need to expand the list of default multi-tags that are used?

    Second, the tag information columns seem to indicate that I can supply values at capture time that can be used later. Is this where I make the references to the similar panels unique?

    Third, when I capture more than one window with the same name, I have to rename the window ID to pass compilation. Will this mess up references to the panel during test execution.

    Fourth, what is the difference between the following notations?

    Window1.Cancel.Click()

    Window1.PushButton(“Cancel”).Click()

    It seems like the first uses the Pushbutton identifier and the second uses the tag. Is it that simple?

    In terms of the generalized java Setup, I have included SilkTest_java2.jar in the classpath at execution time. I think the Java setup is OK at record time because it is recognizing the Java controls when creating window declarations.


    ------------------

  2. #2
    Guest

    Re: Testing Java Applications

    I am trying to understand the issues you have. It would be good if you could give simple example for each issue.

    Anyway, based on my understanding...

    1.) You are testing multiple java apps (Installers / Uninstallers etc.)
    2.) A part of window declarations for some apps are similar
    Example:
    test1.inc
    ---------
    window JavaMainWin Installer1
    tag "$Installer"
    JPanel TestPanel1
    tag "$JPanel"

    test2.inc
    ---------
    window JavaMainWin Installer2
    tag "$Installer"
    JPanel TestPanel1
    tag "$JPanel"

    3.) You have scripts (scenarios) that go through multiple apps at same time


    Now my answers to the issues are...

    1.) You need to use Caption, WindowID and Index as tags enabling multi-tag options.
    2.) I didn't get your question here. Could you elaborate more on this?
    3.) You can rename the window name. It won't have effect on your scripts
    But, the best approach is defining classes for panels that are similar in multiple apps

    4.) No. It's not simple. The major difference is maintenance of Test Scripts. If all your
    scripts are written with the notation "Window1.Cancel.Click()", when window declarations
    are changed you don't have to change all your scripts. You need to just change the window
    declarations and if new objects / controls added, then small changes to scripts.

    If all your scripts are written with the notation "Window1.PushButton("Cancel").Click()", then
    when the window declarations are changed you have to rerecord all the scripts.

  3. #3
    Senior Member
    Join Date
    Feb 2000
    Posts
    1,497
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Testing Java Applications

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Dan Skibba:

    First, should I use the default Record Window Declarations Options? Will I need to expand the list of default multi-tags that are used?
    <HR></BLOCKQUOTE>
    The standard settings are adequate for most purposes. Experience will eventually dictate where alternatives make sense. I suggest avoiding multi-tags until you're more familiar with the process. They can lead to problems because of their tendency to pick the first match, rather than the best match. Reliability in automation is enough of a challenge that avoiding the introduction of new variables and their implied assumptions is a very good thing.

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>
    Second, the tag information columns seem to indicate that I can supply values at capture time that can be used later.
    <HR></BLOCKQUOTE>
    Not really unless I misunderstand your question. The result of a Record/Declarations operation is just a snapshot at one instant in time. It provides a simple cross-reference from a human-reference-able name to a tag which represents the GUI side identifier. Many adjustments are necessary to both names and tags.

    Note that tags can be replaced with functions and/or variable names. The former supports creating a run time tag determined by the return value of the function which will run every time the tag is referenced in a method call. The latter, variable names, essentially act as runtime constants.

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>
    Is this where I make the references to the similar panels unique?
    <HR></BLOCKQUOTE>
    Initially I'd say no because your requirements are to support multiple, simultaneous installers and uninstallers which in effect (I assume) are different applications. Each of these are best tackled with completely separate and distinct declarations. From your example above you might capture the declarations for each of the different installers and uninstallers. From there you'd extract their common characteristics, containers and methods and place them into class definitions leaving the truly unique characteristics to declarations and methods inside individual instances.

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>
    Third, when I capture more than one window with the same name, I have to rename the window ID to pass compilation. Will this mess up references to the panel during test execution.
    <HR></BLOCKQUOTE>
    You don't want to do this because you will create a maintenance headache. Use the class approach outlined above instead to encapsulate all of the common code. Let’s say you simultaneously need 2 installers and one uninstaller. The code to create them could be as simple as:

    InstallerClass InstallerA {tag "... }
    InstallerClass InstallerB {tag "... }
    InstallerClass InstallerC {tag "... }
    UnInstallerClass UninstallerA {tag "... }

    These are now completely unique and independent instances which can be used in any way desired.

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>
    Fourth, what is the difference between the following notations?

    Window1.Cancel.Click()

    Window1.PushButton(“Cancel”).Click()

    It seems like the first uses the Pushbutton identifier and the second uses the tag. Is it that simple?
    <HR></BLOCKQUOTE>
    More or less, yes. The first format uses the generalized label for the Cancel button as it is identified in the declarations for Window1. The second example uses the dynamic form of class("instance-name") that doesn't require a declaration for the cancel button. I'd suggest using the first form to keep things simple and to limit eventual maintenance. Again, experience will dictate when the latter offers an overriding advantage, which usually isn't very often.

    Good questions, Dan. I hope this lengthy reply is useful.

    John



    ------------------

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.0.9 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Questions / Answers Form provided by vBAnswers (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominatevBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 11:04 AM.

Copyright BetaSoft Inc.