Christian Hargraves

Ranch Hand
+ Follow
since Jul 01, 2003
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Christian Hargraves

Sorry it took so long. I normally watch the Jameleon forums for questions. I just happened to have seen this show up in Google.

The answer is there is no current plug-in for Excel. However, Jacob (which Jiffie uses) claims to be able to automate M$ office products, including Excel. You want to check them out and if you have some luck, maybe we can write a simple plug-in in Jameleon.
17 years ago

1. in what format my testcase should be saved( .xml , .txt, or etc)


The test cases are in xml.

2. where can i save my testcase ( in the jameleon tutorial the he asks to save under scripts/validLogin.xml his example testcase) but i could not find the scripts folder inside jameleon


Then create the scripts folder. Hopefully, you are looking in the
jameleon-tutorial folder. Actually, it doesn't matter where the tests
are placed, you just need to tell Ant where they are.

3. how to execute the test case?


Currently, there is only one provided way, using a provided
Ant task.
However, there is work being done a GUI to help with this.

Does this help?

You may get faster responses by posting directly to the provided Jameleon forums
19 years ago
What kind of help do you need?
19 years ago
Htmlunit (http://htmlunit.sf.net) is supposed to have some Javascript support.
20 years ago
seems that bug might be in the way a URL is defined with the file protocol. I noticed you used file:// and I used file:/ which seems to work.
20 years ago
I use the latest 1.5.4 release of httpunit and I don't have any problems, but I am doing something a little different.
If you are on the C: drive, and running your tests on the same drive, then you can use "file:/htmlDir/htmlFile.html" and it works great. Or you can also use a relative directory like "file:./htmlfiles/test.html" and that works fine too.
20 years ago

I am still not convinced by this. In FIT, the fixtures present a quite valuable abstraction from the interface of the application, so I'd think that it could be made as immune to changes. And reusability can be achieved by using reusable pages in FitNesse, so it seems to me?


You're right, you could make your tests more immune to changes in almost any framework. That's a programming practice and the person writing the tests must adhere to this practice to keep their tests as resuable as possible.
Jameleon, however, was designed with the idea that not everyone thinks about keeping their tests resuable. Jameleon helps foster the practice to those that aren't as familiar with OOP (such as testers) as most developers are.

On the other hand, the documentation effect of FitNesse might suffice for many projects.


This is a very nice feature in FitNesse. I believe keeping your test case docs and your automated scripts together in the same place is crucial in keeping test automation central to your testing efforts. Without good docs, it's so easy to forget what exactly the test is doing.
However, I don't see how this solution compares to how Jameleon attempts to solve the problem of the docs becoming out of sync with the scripts.

I would really like to read that paper...


I can tell ...
20 years ago
HS Thomas,
I don't believe there is anything out there that is similar to Jameleon. Using something like FIT is much easier to get started in, but Jameleon attempts to make things more reusable and more immune to changes to the application. It also attempts to solve the documentation problems that come with automating tests.
I am planning on writing a white paper about the ideas behind Jameleon. But I keep spending my time adding more features to Jameleon so I haven't been able to document it as much as I would like to (especially the part on debugging strategies).
20 years ago
If you have "admin" type applications that allow you to put an application into the state desired, you can include doing the admin tasks in your test case.
We do that and we also created a few QA SQL packages in our database that we add functions to as needed. Basically, we call these packages to simulate the state we need. We then automate these package calls and call them in our automation. So far, we have been able to do some very complex tests that we weren't able to do manually before (because it was just too tedious and took too long).
We use Jameleon for our testing tool. Jameleon enables us to to create a simple tag that does complex things and then simply place that tag in the tests we want. The whole idea of Jameleon is to be able to break tasks up into independent actions (making simple, clean and easy to maintain code), and then organizing the functions to create a test case. Jameleon also auto-generates our test case docs based on the test scripts so we able to see at a high level where and why the test failed or even what the tests that passed are really doing. And when we change our script our test case docs change.
20 years ago
Also if clicking that button opens a new window, then the latest response could be obtained by the getOpenWindows()(?) function.
20 years ago
Yes that does work with Ant 1.5 and higher.
Take a look at the
examples in the Ant manual
I use this in Jameleon ant it works quite well.
[ November 12, 2003: Message edited by: Christian Hargraves ]
20 years ago
Is there a reason you are using jdk 1.1.7? Swing is not included in anything below jdk 1.2. The "Program Files" can also mess up your classpath and your path if that part of the CLASSPATH/PATH is not quoted.
For #2, your imports are all messed up.
import java.awt.*;//Ok
import java.awt.event.*;//Ok
import java.awt.Container.*; // NOT OKAY
//This is a class and should be "import java.awt.Container;"
import java.awt.BorderLayout; // Ok
import java.io.*;//Ok
import java.io.File;//Ok
import java.io.FileReader;//Ok
import java.io.BufferedReader;//Ok
import java.lang.Exception.*;//NOT OKAY
//No reason to import this as the java.lang package is already imported.
//If you really want to import this, then it should be
//import java.lang.Exception;
import java.lang.Object.*;//NOT OKAY -- Same as the above.
import java.lang.Exception.*;//NOT OKAY -- Second time to import same thing.
import java.net.*;//Ok
import java.util.*;//Ok
import javax.swing.*;//Ok -- but jdk 1.1.7 doesn't come with Swing.
//you'll need swing.jar in your classpath -- try using jdk >= 1.2
import com.meterware.httpunit.*;//Ok
import org.xml.sax.*;//Ok
//import junit.framework.TestCase.*;// NOT OKAY -- same as above
//TestCase is a class -- import junit.framework.TestCase;
20 years ago
Just a thought. This might seem a little strange, but you could put certain text in the javadocs or even the code of the actual tests that represents what type of test it is ( like "DATABASE", "ACCEPTANCE", "UNIT" ..). Then you could use the choose tag in the fileset to select files that only match the text provided. This way, you wouldn't have to have long names, follow a certain package structure nor create test suites and a test could be categorized in multiple ways simply by adding the appropriate text or constant from another class to the file.
20 years ago
According to your original post, it seems like you got the code compiled or else you wouldn't have gotten to the part that says "javascript disabled" and "nekohtml or jtidy not found".
For starters, you don't need to add ANY class files or jar files to your PATH, only to your CLASSPATH. I am guessing that the classpath you are using to compile the files is different from the classpath you are using to execute the files or else, like I said above, you wouldn't even be at the point where HttpUnit is complaining about not being to find files.
How are you executing this files and how are you compiling them?
20 years ago
Do you have both JTidy and Neko in your classpath? JTidy is much more strict as to valid HTML. I see that the exception is coming from Neko and what I can I remember, the default is to use Neko and if it isn't in the classpath, then it looks for JTidy. I might try to do the following:
1) Take out JTidy from your classpath and run the test.
2) Take out js.jar from your classpath and run the test. HttpUnit doesn't care if it is in there. If js.jar is in the classpath then JavaScript is enabled, otherwise it doesn't care.
3) If you are still having problems, then I try connecting to a different page that has VERY simple VALID HTML and try again.
If you still have problems, try posting what exactly you did, the VERY SIMPLE HTML you tried to retrieve and which of these steps you tried.
[ November 12, 2003: Message edited by: Christian Hargraves ]
20 years ago