News: Jameleon 1.4, acceptance-level automated testing tool, released
Jameleon 1.4 has been released. Jameleon is an acceptance-level automated testing tool that separates applications into features and allows those features to be tied together independently, creating test-cases. These test-cases can then be data-driven and executed against different environments.
- Posted by: Christian Hargraves
- Posted on: September 15 2003 22:29 EDT
Some of the enhancements are:
- A test case can now use multiple CSV files, creating nested looping. This will drastically speed up those test cases that require many steps before the final test point begins.
- Mapping variables is now even more robust.
- No need to manually register custom functional points anymore.
- Much needed improved error messages and logging. Switched to log4j which opened up a lot of possibilities.
- Results are now also formatted in HTML, providing links to the state of the application in case of a test case failure.
- Ability to execute test cases based on a criteria.
- Added Assert Levels. These are asserts that can be executed or not, depending on the execution level.
View the release notes for Jameleon 1.4
Go to the Jameleon home page
- other tools? comparison? JUnit? by Test Test on September 17 2003 00:36 EDT
- Another Acceptance Testing Tool by Chris Gardner on September 20 2003 13:52 EDT
Does somebody know of other functional testing tools and how this compares to other tools? How does it compare to JUnit? I know Junit a unit testing tool but still I would want to know what features Jameleon provides to be more acceptable as functional testing tool.
There are several functional/acceptance testing tools out there. In the last post made on Jameleon, people listed several other testing tools, including acceptance, function, integration. and acceptance level tools. Unfortunately, when I do a search for "Jameleon" on this site, I dont' get any results.
Please visit this thread on javaranch as a possible answer to your questions.
Basically, Jameleon is mean as a tool to solve the problems in the QA world. It is quite robust now. However, I would classify Jameleon as just getting started when I think about all of the features that are planned for it.
...to that other Jameleon article where other testing tools were mentioned:
Here at my place of work, http://www.acxiom.com, we created an XML test framework to test our internal web application. We used Ant and HttpUnit. We extended Ant using new XML tasks and came up with an XML syntax for testing our web application that is vaquely similar to what's in Jameleon.
Our goal was to make our unit tests immune to layout changes in the application.
We acheieved that goal OK (not as well as Jameleon does) but we didn't do so well when it comes to supporting data-driven tests (we use Ant to manage property files and use Ant property names in our tests).
I've only read through the docs on the Jameleon site (hey, nice docs too!) but I haven't seen any other test tool that would achieve the goal of making maintainable and reusable test cases as well as Jameleon. I'm very impressed so far. I'm definitely gonna try this tool.
Thanks for your reply and your interest. I worked very hard on the documentation, but I ended having to do two emergency releases, mostly fixing the documentation. If you tried the tutorial out today, I am afraid you will have been very dissapointed.
I just barely fixed all of the stupid mistakes in the tutorial part 1 and totally redid tutorial part 2. I had some of my friends neither of whom were programmers and not familiar with Jameleon go through the full tutorial before I released it this time.
If you one of the poor souls trying to make it through the tutorial, I am very sorry.
For acceptance testing, I'm using FitNesse (http://fitnesse.org/) from ObjectMentor.
FitNesse is a wiki that uses the FIT framework (http://fit.c2.com/). FitNesse encourages customers to document their requirements (user stories) and make them executable in the wiki itself. The input and validation is specified through HTML tables. The FIT framework interprets these tables and calls out to an appropriate "fixtures," which is custom code that calls out to the application and interprets responses.
Overall, I'm pretty pleased with the product. Writing fixtures, however, can get involved, depending on your interface. For example, if the only interface to your application is a socket over which you must sling XML, all that XML formatting and validating (even with tools such as JAXB or DOM) is tedious.
I started to use Fitnesse. Can you please help me how to test a simple .ear file using fitnesse?