Jameleon - Frequently Asked Questions

General Questions

1. Why the Name Jameleon?
2. Who designed the logo?
3. What types of applications can Jameleon test?
4. Can I use Jameleon to test my web application that uses X technology?
5. What plug-ins are currently available?
6. Which file should I download?

Execution or Registration of Custom Tags Questions

1. How do I see whether X tag is getting executed?
2. Why isn't my tag getting executed?
3. Why isn't my tag getting registered?

Data-driving Questions

1. How can csv/sql tags be used to increment test cases run?
2. Why doesn't my session tag get baseUrl when being set in the script?

General Questions

Why the Name Jameleon?

Jameleon was derived from the word Chameleon. However, this lizard was written in Java. Thus, the term Jameleon. One of the basic concepts behind Jameleon is that just as Chameleons can adapt to their environment, tests written with Jameleon can be run against applications that exist in different environments. Chameleons are also masters at catching bugs.

Who designed the logo?

A co-worker named Matt Grandon. He also did some of the icons and other graphics on the site.

What types of applications can Jameleon test?

Jameleon itself is simply a testing harness that is application interface agnostic. Currently, there is support for web applications and database testing.

Can I use Jameleon to test my web application that uses X technology?

Depending on the plug-in, different types of testing are supported. One of the plug-ins allows for complete control of Internet Explorer while the other web plug-ins simply emulate a browser's behavior and therefore prove more difficult to test web applications that use Java Applets, JavaScript or similar technologies.

What plug-ins are currently available?

See the Plug-ins section on the left for a list of current plug-ins.

Which file should I download?

If you are asking this question, then you should probably download jameleon-test-suite-x.x.x.zip. The x's mean version numbers. This file is a pre-configured version of Jameleon, set up to be used as a test suite. This file has every plug-in and the most common features enabled.

Execution or Registration of Custom Tags Questions

How do I see whether X tag is getting executed?

Since Jameleon 3.0.2, Jameleon fails on unrecognized tags, describing which tag is invalid. This only works for tags tag begin with the namespace defined. In other words, <j:foo-bar/> will fail, but <foo-bar/> won't get recognized and will get skipped. The answer below is for previous versions.

By setting trace="true" in jameleon.conf or in the test case being debugged. This basically prints something out to the console for every tag being executed. For custom tags, the required attribute, functionId, is printed out.

Basically, if the functionId of the tag in question is printed out to the console, then it is being executed.

Why isn't my tag getting executed?

There are a few possible reasons why your tag isn't getting executed in your test script. Please see the possible reasons below:

• The jameleon-test-suite-x.x.x.zip distribution's Ant task is configured to only look for java files that end in Tag.java. In other words, SomeFunctionality.java should be renamed to SomeFunctionalityTag.java. This can, of course, be reconfigured to search for all java files via the Custom Tag Registration Ant Task in the build.xml file in the jameleon-test-suite directory.
• You forgot to run the Custom Tag Registration Ant Task when building custom tags.
• The fileset provided in the Custom Tag Registration Ant Task doesn't match the custom tag you are trying to register.
• The package defined in your custom tag, doesn't match the actual directory structure the tag is in. For example the tag in question defined a package of net.sf, but it exists in net.sf.tags.
• If you are using namespaces, you forgot to add the Jameleon Namespace to your new custom tag. In other words:

  <testcase xmlns="jelly:jameleon">
  
  <test-case-summary>Notice how custom-tag doesn't start with  </test-case-summary>
  <test-case-author>Christian Hargraves</test-case-author>
  <test-case-level>ACCEPTANCE</test-case-level>
  <functional-point-tested>properties</functional-point-tested>
  
  <junit-session application="appName" organization="sf">
  <custom-tag 
      functionId="compare two variables"
      var1="${var3}"
      var2="${var4}"/>
  </junit-session>
  
  </testcase>

  In the above example, xmlns:j="jelly:jameleon", tells the scripting engine to search for all Jameleon-specific tags in the namespace where elements begin with <j:.. Notice how <custom-tag does not have a namespace. The scripting engine will ignore this tag because it doesn't start with <j:. The example below fixes this problem:

  <testcase xmlns="jelly:jameleon">
  
  <test-case-summary>Now custom-tag starts with  </test-case-summary>
  <test-case-author>Christian Hargraves</test-case-author>
  <test-case-level>ACCEPTANCE</test-case-level>
  <functional-point-tested>properties</functional-point-tested>
  
  <junit-session application="appName" organization="sf">
  <custom-tag 
      functionId="compare two variables"
      var1="${var3}"
      var2="${var4}"/>
  </junit-session>
  
  </testcase>

  Of course, not using namespaces in the first place would resolve this, assuming you aren't using the jelly core tags:

  <testcase xmlns="jelly:jameleon">
  
  <test-case-summary>Now custom-tag starts with  </test-case-summary>
  <test-case-author>Christian Hargraves</test-case-author>
  <test-case-level>ACCEPTANCE</test-case-level>
  <functional-point-tested>properties</functional-point-tested>
  
  <junit-session application="appName" organization="sf">
  <custom-tag 
  functionId="compare two variables"
  var1="${var3}"
  var2="${var4}"/>
  </junit-session>
  
  </testcase>

Why isn't my tag getting registered?

There are a few possible reasons why your tag isn't getting registered. Please see the possible reasons below:

• You forgot to run the Custom Tag Registration Ant Task when building custom tags.
• The fileset provided in the Custom Tag Registration Ant Task doesn't match the custom tag you are trying to register.
• The package defined in your custom tag, doesn't match the actual directory structure the tag is in. For example the tag in question defined a package of net.sf, but it exists in net.sf.tags.

To check to see if your tag is getting registered, a file called "TestCaseTagDefs.properties" should be generated by the Custom Tag Registration Ant Task. This file is in the format of tagName=package.of.custom.tag.class. Look for your tag in this file. If it isn't in there, this means your tag isn't getting registered.

Data-driving Questions

How can csv/sql tags be used to increment test cases run?

If you set countRow to true, then not only will Jameleon count each row as a test case, but it will also continue to execute even if the previous row fails. This is attribute is common across all Jameleon-provided data-drivable tags. Please see the documents on tag of interest for more information.

Why doesn't my session tag get baseUrl when being set in the script?

This question is specific to why when the variable is set in a properties, it can't be used directly in a session tag. For example, why does the following not work:

<testcase xmlns="jelly:jameleon">
<hu-session application="appName" baseUrl="${someUrl}">
...
</hu-session>
</testcase>

or even

<testcase xmlns="jelly:jameleon">
<hu-session application="appName" baseUrl="${baseUrl}">
...
</hu-session>
</testcase>

And why does the following does work:

<testcase xmlns="jelly:jameleon">
<hu-session application="appName">
...
</hu-session>
</testcase>

The properties files are read in during the execution of the session tag itself. The problem is that Jelly tries to resolve ${} variables before the session tag is actually executed. And because the ${} variables haven't be read in yet, Jelly resolves them to nothing.

Most plug-ins have gotten around this, by supporting both context variables and direct settings for the baseUrl attribute. In other words they support setting the baseUrl to a hard value like: baseUrl="http://some.domain.com" or they support reading them in directly via the properties file, but they don't support setting the value in the script via the context variable.

If you still don't understand the answer, just refer to the above examples. Set the baseUrl variable in your properties file, but don't set it in the script. Setting the application="appName" magically does this for you.