The framework jar includes a base class for tests with many utility methods.
You can read a module descriptor and convert it into a registry. Create a test service and extend the implemention with the interceptor. Invoke the methods of the service to see if the interceptor does its job. For example, imagine a transaction interceptor, that starts, commits and rollsback transactions around service methods. You should abstract out the transaction start, commit and rollback into a service and provide a mock implementation of the transaction service that simply logs what it would have done. You can then invoke service methods of the test interface to ensure that the interceptor invokes the supporting service (the transaction service) properly. You may not be able to get full coverage of the actual transaction service itself outside of integration testing, since it will likely require an actual application server to be running. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com > -----Original Message----- > From: Johan Lindquist [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 02, 2003 3:36 AM > To: Jakarta Commons Developers List > Subject: [HiveMind] Testing Interceptors ... > > > A general question: What do you all consider best practices > for testing > interceptors? Currently involves a lot of manual testing, > but would like > to move to junit testing for it. > > Johan > > -- > you too? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
