For component tests stubs are required with in-memory dummy implementations of certain OSGi, JCR, Sling and WCM features, including JSON mount of JCR data
Sling and Jackrabbit has implemented such stubs as well, before migrating our stubs we should analyze them and use them if possible
Otherwise we need to implement our own stub environment for Sling/WCM-based component tests
Integration tests
open
For Sling-based integration tests Sling already provides a good infrastructure which can be run automatically from a maven project - it uses a real sling instance against which the integation tests are run
For AEM-based integration tests we have to check what Adobe provides - or develop a similar environment as used by sling ourselves. Or use an external CQ instanze to deploy the integration tests and run them remotely - and make sure all is cleaned up again after the tests are finished (complete or incomplete).
Acceptance / UI tests
Hobbes is much more mature now and hopefully open-sourced in the future. For Selenium & Galen we have http://qa.wcm.io/galenium/
Acceptance tests are run using selenium or comparable tools using a browser as frontend
Evaluate the "Hobbes" framework which is integrated in CQ6 and the Touch UI as acceptance test framework
We have to check if we need generic features that is shared across projects
On feature is overriding configuration options from the remove test scripts during a test run - a proposal based on HTTP header injection is described in Testing
done
open