arquillian android container implementation

[smikloso]

Hi all,

I started to code a container for android devices, I just took the whole concept of Arquillian - creating archive locally, deploying it to the container which enriches it and tests are executed - to the Android platform, so I basically code against DeployableContainer (1). I am doing it like managed container.

I know that there is Arquillian Drone & Android extensions, on which the code is based heavilly, but just internal logic is little bit different, I am following container lifecycle and all that pattern, inspite of using observers and events.

I polished the code a lot, refactored it here and there, repaired some bugs and made the code more concise and robust, I added some features too, e.g. automatic creation of AVD in case none is defined in the container descriptor (plus all possible combinations, e.g. when phone serial code is bad, avd is started, if it is not present in the system it is created and deleted after tests and so on ...)

The main reason I am writing this thread is because I am litte bit on the crossroad right now. I do not quite understand how to implement deployment of the archive to the android device as such. I have (in my head ) all concept of testing of native android applications, not only web-based one, but the crucial point is to somehow be able to get that archive to the android as such. There is a way how to install some APK via AndroidDevice in Android extension but I would like to make it in the way you can specify @Deployment method as easily as via normal containers and you do not have to install it manually in test methods like here (2)

I identified two ways how to deal with it:

1) create APK archive for ShrinkWrap just the same way as JavaArchive is done - means coding the whole fluent api for the apk archive

2) install prepared APK file manually via means of AndroidDevice in the Android extension.

The first options seems to be more "clear" but it is also harder to do. But it opens so many doors to hook other features ...

The second big problem is that I am somehow lost in the programming as such, following this image (3) I am just on the "Container Deploy", I am about to code the part between "test method" lines, where things are going to be, from the implementation point of view, really complicated. I guess I has to implement AuxiliaryArchiveAppender but do I have to implement my own DeploymentPackager? What's the difference between AuxiliaryArchiveAppender and AuxiliaryArchiveProcessor?

In general, it is a good idea to code against the container.test.spi.* interfaces? How about the "another side" of the test? I am not quite sure how to catch all these things in the android device. Do I have to implement my own protocol?

Thank you for reading this, you can check the code here: https://github.com/smiklosovic/arquillian-container-android

It does pretty nothing but it starts emulator or device, you are welcome to test it via test artifact.

1) http://docs.jboss.org/arquillian/aggregate/latest/org/jboss/arquillian/container/spi/client/container/DeployableContainer.html

2) https://github.com/arquillian/arquillian-extension-android/blob/master/android-tests/src/test/java/org/jboss/arquillian/android/example/AndroidApkInstallationTestCase.java

3) http://docs.jboss.org/arquillian/reference/1.0.0.Alpha5/en-US/html_single/images/spi-overview-small.png

[smikloso]

Hi guys,

I made some progress in implementing that android container, you can check it here:

https://github.com/smiklosovic/arquillian-container-android

Right now, you can combine Android container with normal JBoss AS container and do testing of your application in very easy way, check this:

https://github.com/smiklosovic/arquillian-android-container-tests/blob/master/android-jboss/src/test/resources/arquillian.xml

You can specify which deployment you want to operate upon, you can even put various implementations of the containers into one container group, yay! so sweet ~_~

And what about testing your application which are running in JBoss AS from the Android device in one test? Lets see how your pom.xml will look like:

https://github.com/smiklosovic/arquillian-android-container-tests/blob/master/android-jboss/pom.xml

Check dependencies, here are really only these:

            <dependencies>

                <!-- JBoss AS 7 managed -->

                <dependency>

                    <groupId>org.jboss.as</groupId>

                    <artifactId>jboss-as-arquillian-container-managed</artifactId>

                    <version>${version.jboss.container.managed}</version>

                    <scope>test</scope>

                </dependency>

                <!-- Android Container Depchain -->

                <dependency>

                    <groupId>org.jboss.arquillian.container</groupId>

                    <artifactId>android-container-depchain</artifactId>

                    <type>pom</type>

                    <scope>test</scope>

                    <version>${project.version}</version>

                </dependency>

                <!-- Android Drone for web testing -->

                <dependency>

                    <groupId>org.jboss.arquillian.extension</groupId>

                    <artifactId>arquillian-container-android-drone-web</artifactId>

                    <version>${version.android.drone.web}</version>

                    <scope>test</scope>

                </dependency>

Container depchain tells you are using Android Container, just like you are using JBoss AS, so right now you are using two different container implementations!

Android drone web is the extraction of the android drone from the arquillian-extension-android, by this way, we can hook several drone implementations so you can specify how your android device will behave like while testing.

You are welcome to hack around the code, all ideas are highly appreciated.

[aslak]

This is awesome stuff.. !

Sorry for the late reply..

1) The need for a ShrinkWrap APK Archive has come up before. I don't think it was ever started, but it would make a very interesting addon. Tho no strictly required as you could always jsut import complete apk archives via ZipImporter.

> The second big problem is that I am somehow lost in the programming as such, following this image (3) I am just on the "Container Deploy", I am about to code the part between "test method" lines, where things are going to be, from the implementation point of view, really complicated. I guess I has to implement AuxiliaryArchiveAppender but do I have to implement my own DeploymentPackager? What's the difference between AuxiliaryArchiveAppender and AuxiliaryArchiveProcessor?

The communication between the Arquillian Client side and InConainer side is handled via the Protocol SPI. This is only used when a test is set to run inside a given DeployableContainer/Deployment. The role of the Protocol is to 'somehow' setup a communication channel between the Client and Container for executing TestClasses in container. The DeploymentPackager is part of the Protocl SPI and gives the Protocl the means of modifying the User defined @Deployment to allow it to setup the communication. in e.g. the Servlet Protocol, the DeploymentPakcager will append all AuxilliaryArchives and add a Servlet to the Deployment somewhere, it might even change a jar to be a war to allow for the Servlet to be added. You can find a little bit more info on Protocols here: https://docs.jboss.org/author/display/ARQ/Protocols describes some of the Packaging rules etc

The AuxilliaryArchiveAppender can be used in the cases where, 'all i need is for some extra classes to be added to the final deployment'. E.g. to run JUnit incontainer, we need to add the JUnit jar to the deployment. This is the AuxilliaryArchiveAppenders job. You don't know how it will be packaged, you just know that we need these classes to run in the target environemnt.

The AuxilliaryArchiveProcessor is not really used anywhere at this point as far as I remember, but it gives you a chance to modify the Archives produced by the AuxilliaryArchiveAppenders. e.g. you need to add something specific to someone elses jar? rewrite a class packaged by someone else?

In the case of the Android Container, I would imagine it requiring it's own Protocol. Somehow you need to produce via the DeploymentPackager a Deployment that when installed opens up some Communication form so the Client side of the Protocol (TestMethodExecutor) can say: execute Test A Test Method B. Android might have some loophols to execute arbatrary code within a application without having to modify the original APK, so the DeploymentPackager might not be needed (tho you still need to install the Arquillian / Junit libs etc in the device somehow).  I'm not to familiar with how the Android APis work..

[smikloso]

Thank you for the very valuable summing of that group of classes, it is more understandable and clear now. Regarding of your last paragraph, yes, that is something I am going to implement and I have some ideas but it is quite open area. The very first thing will be about making Android device and Arquillian communicate between each other, which can be done in various ways. It is very nice that there is already the way how to get some package or files as such to an Android device because this is already implemented by Karel's android extension (for example when installing the android-server.apk you would use it), so using this feature is "for free" and there is no need to reinvent the wheel (so deploying an archive equals to using that feature and hook it in the proper place, deploy() method in the container lifecycle is more then suitable) and by this way I can also do all that magic of modifying an APK.

Regarding of multiple containers in the arquillian.xml, I noticed that when I am going to use two Android containers in one group, the second Android container is not started, only the first one is (or vice versa). It seems to me that the configuration of the second container somehow rewrites the first one ... This behaviour is strange and I do not know why it is happening precisely, but when I look at the code of jboss as container, there is ServerManager (not sure about exact name of the class) which creates and starts various instances of servers as separate processes (right?). This feature is missing in my Android container and I do not see a way how to implement it, so in this moment you can use only one instance of Android container and you are not able to do something like android cluster Don't you have some idea what should be done?

Thanks a lot for any feedback!

[smikloso]

For those who are interested in how testing with JBoss AS and Android Container fits together, you are welcome to check this repository with examples

https://github.com/smiklosovic/arquillian-android-container-tests/tree/master/android-jboss

arquillian.xml is like this:

https://github.com/smiklosovic/arquillian-android-container-tests/blob/master/android-jboss/src/test/resources/arquillian.xml

pom.xml is also very readable:

https://github.com/smiklosovic/arquillian-android-container-tests/blob/master/android-jboss/pom.xml#L129

[aslak]

When <container> elements are configured within a <group>, a instance of DeployableContainer is created pr <conainer> configuration. As long as the DeployableContainer instance is capable of creating/connecting to multiple Containers within the same JVM / Classpath it should work.

[smikloso]

The problem is that code is based on arquillian-extension-android which is event driven, methods are observing them, so when I fire some event, that event is swallowed by "both containers".

[aslak]

Right, the handling of the Emulator/Device needs to be extracted outinto a 3. module that is used by the 'Drone WebDriver' and the DeployableContainer. The DeployableContainer needs to control it's own instance

[smikloso]

Hi, just one quick question, in the current implementation of the arquillian-extension-android, there is a ResourceProvider like this

https://github.com/arquillian/arquillian-extension-android/blob/master/android-impl/src/main/java/org/jboss/arquillian/android/enricher/AndroidDeviceResourceProvider.java

With that note in mind, that we are not able to provide more than one android device as an ArquillianResource, how would that be even possible? I mean, let's say that I extend ResourceProvider class which can lookup for objects of some type. But these objects have to be somehow injected into that ResourceProvider class and I do not see a way how to make it possible when multiple containers are fired up. So basically all containers would have to "see" some ResourceProvider instance to add their own Android device into it - which is very interesting situation.

Is there a way how to "pick" ResourceProvider(s) from the Arquillian in the every container's context (lifecycle), iterate over them, check that some particular resource provider canProvide resource of some type and add the instance of our device into that, so it is looked up upon testing? Qualifier resolution could be done according to device name or similarly ...

It seems this is very similar https://github.com/arquillian/arquillian-extension-drone/tree/master/drone-impl/src/main/java/org/jboss/arquillian/drone/impl but how to bend it is another story ...

[aslak]

If you expose the AndridDevice as ContainerScoped in the Container. The user controlls which AndroidDesvice to inject based on which 'deployment' context (which is linked to a Container context) the Test method is running in. Only one of those are active at a given time.

@Inject @ContainerScoped

InstanceProducer<AndroidDevice> inst;

inst.set(device)

The Resource Enricher stays the same. It only looks up a AndroidDevice from the context, Arquillian Core handles which Contexts are active at the time and which instance it gets.

[smikloso]

I did as you adviced with @ContainerScoped annotation and it works BUT

lets see the test class:

{code}
@RunWith(Arquillian.class)
public class FooTest {
    @Deployment(name = "android1", order = 1, testable = false)
    @TargetsContainer("android1")
    public static Archive<?> createDeployment1() {
        System.out.println("create deployment android1");
        return ShrinkWrap.create(JavaArchive.class, "jbossas1.jar").addClass(HashObjectStore.class)
            .addClass(ObjectStore.class).addClass(Bar.class).addClass(Baz.class);
    }
    @Deployment(name = "android2", order = 2, testable = false)
    @TargetsContainer("android2")
    public static Archive<?> createDeployment2() {
        System.out.println("create deployment android2");
        return ShrinkWrap.create(JavaArchive.class, "jbossas2.jar").addClass(HashObjectStore.class)
            .addClass(ObjectStore.class).addClass(Bar.class).addClass(Baz.class);
    } 
    @Deployment(name = "jbossas", order = 3, testable = true)
    @TargetsContainer("jbossas")
    public static Archive<?> createDeployment4() {
        System.out.println("create deployment jbossas");
        return ShrinkWrap.create(JavaArchive.class, "jbossas.jar").addClass(HashObjectStore.class)
            .addClass(ObjectStore.class).addClass(Bar.class).addClass(Baz.class);
    }
    @ArquillianResource
    SomeClass someClass;
    @Test
    @InSequence(1)
    @OperateOnDeployment("android1")
    public void test01() {
        System.out.println("test android1");
        Assert.assertTrue(someClass != null);
        System.out.println("some class of: " + someClass.getName());
    }
    @Test
    @InSequence(2)
    @OperateOnDeployment("android2")
    public void test02() {
        System.out.println("test android2");
        Assert.assertTrue(someClass != null);
        System.out.println("some class of: " + someClass.getName());
    }
    @Test
    @InSequence(3)
    @OperateOnDeployment("jbossas")
    public void test03() {
        System.out.println("test jbossas");
        Assert.assertTrue(true);
    }
}
{code}

As long as I am trying to use that SomeClass resource just on the "android containers", all is good. It is just a test before real android device will be injected. So basically SomeClass is the resource in the ResourceProvider, registered in the container extension as a service. To be complete, here it is:

{code}
public class DeviceResourceProvider implements ResourceProvider {
    @Inject
    private Instance<SomeClass> someClass;
    @Override
    public boolean canProvide(Class<?> type) {
        return SomeClass.class.isAssignableFrom(type);
    }
    @Override
    public Object lookup(ArquillianResource resource, Annotation... qualifiers) {
        SomeClass sc = someClass.get();
        if (sc == null) {
            throw new IllegalStateException("Unable to Inject SomeClass into test");
        }
        return someClass.get();
    }
}
{code}

I am sure that I got instance of SomeClass of some container because of logs I see in the console.

The problem is when there is the container of the other type, e.g. JBoss AS. It also tries to look up that SomeClass object but it fails to do so, here is the log:

Is there any workaround? I guess there is not because whole multiple containers on the classpath idea is kind of hack so Arquillian counts on the fact that there is just one container to get resources of but

I also tried @OperatesOnDeployment("android1") at the @ArquillianResource annotation but the result is the same ...

java.lang.RuntimeException: Could not lookup value for field org.jboss.arquillian.container.android.enricher.SomeClass net.miklosovic.test.test01.test.FooTest.someClass
          at org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:61)
          at org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:52)
          at org.jboss.arquillian.container.test.impl.ClientTestInstanceEnricher.enrich(ClientTestInstanceEnricher.java:51)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
          at java.lang.reflect.Method.invoke(Method.java:601)
          at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
          at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
          at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
          at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
          at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
          at java.lang.reflect.Method.invoke(Method.java:601)
          at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
          at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
          at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
          at java.lang.reflect.Method.invoke(Method.java:601)
          at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
          at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
          at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
          at java.lang.reflect.Method.invoke(Method.java:601)
          at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
          at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
          at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
          at java.lang.reflect.Method.invoke(Method.java:601)
          at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
          at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
          at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
          at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
          at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.before(EventTestRunnerAdaptor.java:95)
          at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:222)
          at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
          at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
          at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
          at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
          at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
          at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
          at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
          at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
          at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
          at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
          at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
          at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
          at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
          at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
          at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
          at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
          at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
          at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
          at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
          at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
          at java.lang.reflect.Method.invoke(Method.java:601)
          at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
          at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
          at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
          at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
          at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.IllegalStateException: Unable to Inject SomeClass into test
          at org.jboss.arquillian.container.android.enricher.DeviceResourceProvider.lookup(DeviceResourceProvider.java:24)
          at org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.lookup(ArquillianResourceTestEnricher.java:112)
          at org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:57)
          ... 71 more

[aslak]

When the SomeClass is registered in the Container context it will only be avilable when

- the test is running on the client side

and

- running in the Context of a deployment that targets the container,

  or

- you use the @OperatsOnDeployment as a qualifier on the ArquillianResource injection point

In this case you expose the SomeClass in the AndroidContainer, then you run a Test incontainer on a JBoss AS container. At this point you could be on another physical server. Arquillan Resource injections does currently not do any Proxying of the resource it injects (in theory, depending on the API, we could have proxyed the API and do the callbacks to the client and forward it to the container context in question)

Currently we don't do anything to the TestClass either, tho this is planned. Filtering the Class by rewriting it to only include the injections/methods that are used in a Container when we add it to the deployment for that Container. We should have detected that SomeClass was not used in the test03 method and removed the SomeClass injection from the deployed class.

The only workaround now tho, is to use Method Argument injection instead of Class injections.

public void test01(@ArquillianResource SomeClass someClass) {}

[aslak]

or if you were 'normally' executing on the Client side in the context of the jbossas Container Context, you could cross over context on the Resource injection only.

@Test

@InSequence(3)

@OperateOnDeployment("jbossas")

@RunAsClient

public void test03(@ArquillianResource @OperateOnDeployment("android1") SomeClass some) {

          System.out.println("test jbossas");

          Assert.assertTrue(true);

}

(rereading my brain dump here, this is case #2 in the above explanation)