Unit, System and Integration Testing
[
n_alex
]
21:54, Thursday, 18 December 2003
Today I'm beginning the overdue process of determining a clean, reliable and relatively simple way to test the Shocks Framework, applications which run on it and feature platforms which plug into it. To do this will require not only Unit Tests, but also System-level tests and tests to ensure the backwards compatibility of future binary releases.
To do this I'm returning to Matt Albrecht's GroboUtils project. Matt's JUnit extensions show a level of insight into testing that I've not found anywhere else.
In particular, I like the way Matt breaks down the problem space of automated testing into three categories:
1. Unit Tests, which ensure that each Object functions as it ought to
2. Application Integration Tests, which ensure that the entire application functions as it ought to
3. Integration Unit Tests, which ensure that two or more Objects function together as they are supposed to.
He also briefly examines the concept of 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, 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 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.
--
N.
