New Arquillian Drone scopes proposal

[kpiwko]

Hi,

I was discussing Arquillian Droidium ARQ-1557 with Stefan. As a result, I'm thinking of creating new lifecycle scopes for Drones.

Drone currently works following way:

1. Instance is configured and made InstanceOrCallable, defined by an event
2. Instance is created from Callable in Before event - during test enrichment
3. Instance is destroyed, defined by an event

• Class scoped Drone - is defined by BeforeClass and AfterClass
• Method scoped Drone - is defined by Before and After
• new Deployment scoped Drone - is defined by AfterDeployment and BeforeUndeployment
• new Suite scoped Drone - is defined by BeforeSuite and AfterSuite, or BeforeClass and AfterSuite, but definitely available in @BeforeClass method

The purpose of deployment scoped Drone is:

1. Give user ability to get URL of the deployment automatically
2. Give Droidium 1:1 lifecycle mapping for Selendroid usage
3. Make mapping of Drone to Deployment more explicit

The purpose of suite-like scoped Drone is:

1. Allow users to configure browser programmatically once per suite
2. Remove the need to hijack remote-reusable to achieve the same/similar functionality

Examples:

@Drone @OperatesOnDeployment("android.apk")
WebDriver driver;

@Deployment(name="android.apk")
public static Archive<?> myAndroidAPK() { ... }


@Drone(scope=DroneScope.SUITE)
static WebDriver driver;

// default scope is CLASS for field, METHOD for parameter.
// SUITE could be both static and non static, created before class
// DEPLOYMENT would need @OperatesOnDeployment or some custom typesafe way how to define binding for deployment and drone


enum DroneScope { METHOD, CLASS, DEPLOYMENT, SUITE }

Whiteboard:

How does it feel?

Thanks,

Karel

[jhuska]

It looks good IMHO.

Couple of questions to confirm my understanding:

1.

The purpose of deployment scoped Drone is:

1. Give user ability to get URL of the deployment automatically

How will it work in real ? How will be the WebDriver instance coupled with deployment, and how the user can get the URL of it explicitly ? Does it for example mean that calling driver.get("relative/url.html") will prefix a correct context root ? Or is it Droidum specific ...

2. Can you think of some other advantage of SUITE scope driver instance than its availability in @BeforeClass ? Is there some API for cleaning the browser session except WebDriver.close ?

Thanks

[smikloso]

Regarding of 1) I think that when you enter to the first test method (or even before that since it just does not matter when it is open, theoretically somewhere in BeforeClass), web page will be automatically opened for you so you do not need to inject @ArquillianResource URL context into your test and do that manually (almost in all sensible use cases you are doing this in the very first test method all over again). Drone could call it when it is being instantiated. When you have some deployment, you are able to inject @ArquillianResource URL into the test, but you could do that one level deeper with Drone so it would open in for you. When you are not satisfied with the page you got open, you can always do that manually to override what Drone did automatically.

In case of Droidium, when you have @Deployment which is instrumented (by @Instrumentable, it says that you want to drive that APK deployment with WebDriver), you put port number as the argument into it (@Instrumentable(viaPort = "10000") and that in turn means that when you set Drone extension in arquillian.xml and specify its remoteUrl, there is port specified as well. These ports match. By doing this, it is only the implementation thing to connect Drones to deployments and it can be even more simple (in theory, i do not have a poc code in mind) when you specify @OperateOnDeployment on WebDriver.

[kpiwko]

The purpose of deployment scoped Drone is:

1. Give user ability to get URL of the deployment automatically

How will it work in real ? How will be the WebDriver instance coupled with deployment, and how the user can get the URL of it explicitly ? Does it for example mean that calling driver.get("relative/url.html") will prefix a correct context root ? Or is it Droidum specific ...

This is twofold at this moment:

• Relative URL support in get methods
• Set browser metadata to point to correct URL - this is mainly valid for Selenium 1

I do not plan to implement automatic opening, because I believe this is work for @InitialPage

2. Can you think of some other advantage of SUITE scope driver instance than its availability in @BeforeClass ? Is there some API for cleaning the browser session except WebDriver.close?

One time setup and a bit faster execution - simulating remoteReusable per suite.

[aslak]

Any chance that a Suite scoped browser can be configured(attempted) differently between two Test's in the same suite?

Illustration:

TestX

@Drone(Suite, someValue=2)

TestY

@Drone(Suite, someValue=4)

Now which value does the Suite scoped Drone have?

I guess the metadata to locate a instance is Scope+Qualifier and all config is external.

[kpiwko]

First hit of @Drone(Suite) will create a browser. Any subsequent @Drone(Suite) will just retrieve existing instance. Instance is disposed after suite is finished.

If user wants to have two suite scoped Drones, he would need to use qualifiers.