A framework for implementing XML script-based integration tests.

See:
Description

Fixture

ca.intelliware.amakihi.fixture	A basic fixture for running Integration Tests against a project
ca.intelliware.amakihi.fixture.util

Web Proxy

ca.intelliware.amakihi.web.servlet

Other Packages

ca.intelliware.amakihi.actor
ca.intelliware.amakihi.actor.http
ca.intelliware.amakihi.util.http
ca.intelliware.amakihi.util.performance
ca.intelliware.amakihi.util.property
ca.intelliware.amakihi.util.xml
ca.intelliware.amakihi.validator

A framework for implementing XML script-based integration tests.

Design Considerations

The Amakihi framework was developed by Intelliware Development while working on a project to deliver a set of EJB services for a large financial institution. We had the following objectives in mind, initially:

• We wanted to be able to run integration tests directly against an EJB framework, rather than a web UI.

  We were using a stateless EJB front-end to the whole system that exchanged standard JavaBean objects (what Martin Fowler would call Data Transfer Objects) with web tier written by another company.

• We wanted to exploit the power of existing tools, notably JUnit.

• We're religious about the value of repeatable, automated tests. As a result, we wanted to automate all test scripts and run them during the nightly build.

  We'd had a lot of success on past projects writing up Integration Tests using HttpUnit, although we acknowledged that there's a non-trivial cost associated with coding HttpUnit test cases.

• We wanted to limit the amount of programming involved in adding a new script, so that we could delegate most of the work of developing the scripts to a group of Quality Assurance people (who weren't programmers by any stretch of the imagination).

  Ultimately, we decided on an XML-based "script" format that allowed us to submit Java beans to the stateless session facade, and which allowed us to inspect and validate the returned beans. (If our front-end was a web application, rather than an EJB layer, we probably would have used Canoo's WebTest.)

  Some additional simple utilities made it easy for us to generate documentation about the scripts.

• Having had good success with using this framework on an EJB layer, we believed that the implementation could be generalized to HTTP-based applications.