A global extension ArquillianSpockExtension
(of type org.spockframework.runtime.extension.IGlobalExtension
) is used to hook into the Spock/Sputnik testrunner lifecycle.
This allows an @Deployment
method specified in a Specification
to be found (indirectly) by the Sputnik testrunner:
- The
ArquillianSpockExtension
builds a new instance of an ArquillianTestRunnerAdaptor
. This adaptor is used to manage the Arquillian lifecycle. - An
ArquillianInterceptor
(that references the previously createdTestRunnerAdaptor
) is established as an interceptor for severalSpec
method kinds: SETUP_SPEC, CLEANUP_SPEC, SETUP, CLEANUP and FEATURE. - When the Sputnik testrunner fires a method of type SETUP_SPEC, the
ArquillianInterceptor
intercepts this invocation to direct theTestRunnerAdaptor
of Arquillian to fires it'sBeforeClass
event. At this point, managed/embedded containers would be started by Arquillian. A deployment scenario is generated if a@Deployment
method is detected, and the created (and enriched) archive is deployed. - When the Sputnik testrunner fires a method of type FEATURE, the
ClientTestExecutor
of Arquillian (that observes theTest
event) fires aRemoteExecutionEvent
that triggers theRemoteTestExecuter
of Arquillian to send a request to execute the desired method on the container. In the container, theServletTestRunner
(present due to the Servlet protocol), delegates the execution of the test method to theSpockTestRunner
class (that is deployed along with theSpecification
classes) on the container.
In the JBehave integration the Arquillian
testrunner performs all the necessary activities of:
- starting containers,
- handling
@Deployment
methods, - running the tests (both in-client and in-container),
- and delegating the actual execution to the
Embedder
/Embeddable
instance.
In the Spock integration, the Sputnik
testrunner relies on the Arquillian-Spock extension hooking onto the test lifecycle of a Specification
. Once the necessary hooks have been established, Arquillian intercepts the events on the client (and establishes a communication channel with the server) to execute the methods in-container, apart from performing the necessary activities.
We'll need features within the Thucydides API to intercept the various events in a Thucydides test lifecycle. For instance, we'll need to intercept the BeforeClass/BeforeFeature event (or the equivalent event in Thucydides), to start the Arquillian TestRunnerAdaptor
, to eventually start the containers and deploy the tests. Also, such events should contain information about the actual Test
instance so that the @Deployment
method can be located by Arquillian.
For now, the Thucydides-Arquillian example uses the StepListener
interface of Thucydides to hook into the suite start and end events, with each suite composed of a single test class or (easyb) story. ThreadLocal
s are used to store state within the StepListener
, primarily since the testSuiteFinished
event does not provide information about the Class or Story whose suite has finished.