I am getting ready to go into the world of
Java, and Java Applets. I am wondering how
much help I can expect from my old friend Silk? I have "heard" that Silk cannot test applets or at least not very reliably.
Is this Bunk? Also that Java test tools cannot drive applets except through apletviewer and hot java .. more phoney baloney or the real skinny?
Finally I have a QA Pal who writes:
Rick, have you used Silk with Java applications much? Silk is not
recognizing child windows of our main XYZ application, which is a major roadblock...
Is this a true technical limitation. Does anyone have a simple solution to get Ryan back on track?
I appreciate any and all response a great deal. I always like to hear from those who actually do this type of testing out there. These forums are tremendous for exposing all the knowlege that exists from various sectors!! Also Beta-Soft is a very strong leader in making that happen .. way to go AJ!
This will help me get a generic handle on automating the Java Front end. I strongly suspect (even though I have a love hate relation with Silk) that if Silk cannot do this .. most likely no one else can.
BTW I have worked with Segue long enough to not even try tech support. I am letting our support license expire .. because Segue Support Sucks (and that aint no phoney Baloney!)
Sr. QA Engineer
re. Silk not recognizing child windows of a Java application... I've encountered this and have not found a deterministic root cause for all cases but have found that an important subcase is where your system CLASSPATH is not set up correctly or points to the wrong "flavor" of Java support in Silk -- notably <silk>\javaex\SilkTest_Java1.jar or Java2.jar.
Other relevant things to check are any support libaries your application uses such as SWING.
Even with all the above sometimes Silk gets confused. In these situations I've found that forcing Silk into a debug mode for a any of my scripts sometimes provides Silk with a "bump" of some kind and then the windows start to be recognized.
Hope this helps...
Donald R. Bosart
Portland, OR, USA
My advice to your friend is to attend the 1 day course (Testing Java Objects) by Segue.
It solved a lot of problems for me! Usually they were setup issues, and others I just had no idea Silk could so that!!!
My 2 cents are: Silk is by far the best Java test tool out there. If all fails, you can always grab the methods out of each Java class and call them using embeded Java Code within Silk. Granted that SilkTest has a bug here and there (sometimes it cannot record Java class methods on some machines) But the funny thing is, install Silk on another machine and you can read the classes? it's a really weird bug, one that nobody can explain yet, but it still works. There's always a workaround, the workaround if you cannot record class methods is to go and ask an engineer!
Silk has many features that sometimes it is even dengerous to have. Yes Slk has the ability to make a call to component API directly without any extension. You can write your own Java class file that can give the freedom of doing virtually anything you want on the object. This helps when the object is not seen by Silk like DataSources or Images or Grid's cells etc. At the same time Silk has the same limitations that all the other tools have, they are all "see" object extended from Component class and not see objects that are extended from Object class. Another thing is in order to really use all the power Silk has you have to able to write code in Java or at least understand Component's documentation. But overall it really fun using Silk when testing Java apps.
BTW Silk 5.0 has some really bad performance problems when working with JDK1.2.2. I filed request with Segue and send thm all my sources. Hope they will find what is the problem.
We're testing a Java app based on JDK 1.2.2 and Swing using SilkTest v5.0.1. All but the JavaMainWin and the Menu/MenuItems are determined to be 'CustomWin's when we do a window declaration. Therefore, we have to create 'winclass' declarations for all our object, either via the class recorder (which only records top level objects in the window z-order) or manually adding them.
Getting the correct 'SilkTest_Java[1|2].jar' passed to the JVM is the key to getting SilkTest to work at all with your app.
If you are invoking your JVM with the '-classpath' switch, this will take precedence over your CLASSPATH environment variable.
SilkTest also 'filters' certain non-visible windows, such as Panels and Canvas, by default. We have found that this can obscure visibility to 'see' a child window of a filtered window. To override the default filtering you will need to add entries to the Extend/JavaEx.ini file under the 'ClassList' section. In this section you specify the class tag and TRUE|FALSE to indicate if the class should/shouldn't be filtered. We've had to do this to get visibility to some of our child windows. One drawback is that once you enable a class in this fashion you increase the window path hierarchy to get to an object.