He also briefly examines the concept of http://groboutils.sourceforge.net/testing-junit/art_eut.html - Enemy Unit Tests , which focuses on the idea that certain dependent units arent' reliable unless otherwise asserted.

The question becomes, how do I properly test the workflow of an application in Shocks? My guess is that, like all feature platforms, a pluggable testing platform could be built on top of the internal framework which (to take a page from the REST architectural style) could monitor the state of the representation throughout the different stages of workflow by using Filters (more specifically, http://shocks.codehaus.org/api/index.html - FilterSupport implementations).

I've already begun drawing up plans for this. Application Integration Tests should be a set of Filters that plug into the framework and can be inserted and removed from workflow at runtime to test that the representational state is behaving properly in a way which can change over time, can be applied at any stage in the application's lifecycle and can be removed so that it does not permanently impact the application's performance.

Of course, there is presently no default platform for managing the representational state--this door is left open intentionally because I know other projects have focused a lot of time and energy on providing this functionality. Recasting their work as a platform module should be very simple.

In the mean time, plain-old Unit Tests can cover a large part of the internal workflow engine, and Integration Unit Tests can be used to check http://shocks.codehaus.org/api/index.html - Sequence components.

Matt also writes about how to arrange tests so they can use other tests. I think that's important and will try to post more information about it when I can.