April 2014 - arquillian-issues - Jboss List Archives

[JBoss JIRA] (ARQ-1528) Be able to start multiple Android containers simultaneously in one test run

by Stefan Miklosovic (JIRA)

[ https://issues.jboss.org/browse/ARQ-1528?page=com.atlassian.jira.plugin.s... ] Stefan Miklosovic commented on ARQ-1528: ---------------------------------------- Since Android undeployment logic was aligned with Arquillian way in ARQ-1557 there is not theoretically any problem to approach to support multiple Android containers in one test run. The only problem is that Android container is configured in arquillian.xml in container element which contains properties related to Android SDK and these configuration properties can not be (or should not be) specified in both container defs. For example, having androidSdkHome in both container elements does not make much sense since you have always one Android SDK installed locally and there is e.g. only one ANDROID_SDK_HOME environment property. In theory, maybe it could be possible to have multiple Android SDK installations but it seems to me as overkill. New approach would "extract" Android SDK related properties from Android container definition to standalone extension, it would look like this {code} <group qualifier="containers" default="true"> <container qualifier="android_1" default="true"> <configuration> </configuration> </container> <container qualifier="android_2" default="true"> <configuration> </configuration> </container> </group> <extension qualifier="android-platform"> <property name="androidSdkHome">...</property> // all jar signers stuff and so on </extension> {code} > Be able to start multiple Android containers simultaneously in one test run > --------------------------------------------------------------------------- > > Key: ARQ-1528 > URL: https://issues.jboss.org/browse/ARQ-1528 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Priority: Blocker > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1757) Move @Instrumentable annotation from @Deployment method to @Drone injections

by Stefan Miklosovic (JIRA)

Stefan Miklosovic created ARQ-1757: -------------------------------------- Summary: Move @Instrumentable annotation from @Deployment method to @Drone injections Key: ARQ-1757 URL: https://issues.jboss.org/browse/ARQ-1757 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Extension - Droidium Affects Versions: droidium_1.0.0.Alpha5 Reporter: Stefan Miklosovic Right now it is like {code} @RunWith(Arquillian.class) @RunAsClient public class TestCase { @Drone private WebDriver driver; @Deployment @Instrumentable public static Archive<?> getAndroidDeployment() { return APK; } } {code} There is a need to move @Instrumentable from @Deployment method to @Drone injections since once someone has WAR deployment deployed to AS and he wants to test it from Android, putting @Instrumentable on @Deployment method in this context does not make any sense. First attempt to attack this problem is to implement it like this for APK instrumentations {code} @RunWith(Arquillian.class) @RunAsClient public class TestCase { @Drone @Droidium private WebDriver driver; @Deployment public static Archive<?> getAndroidDeployment() { return APK } } {code} In case there is only one deployment method, it will be automatically resolved to instrument that one deployment. In case there are multiple deployment methods, it will follow this logic: {code} @RunWith(Arquillian.class) @RunAsClient public class TestCase { @Drone @Droidium @OperatesOnDeployment("android-deployment") private WebDriver driver; @Deployment("android-deployment") public static Archive<?> getAndroidDeployment() {} @Deployment(jboss-as-deployment") public static Archive<?> getJBossDeployment() {} } {code} {{Droidium}} annotation could extend @Drone annotation so it would simplify marking Drone injection as Droidium-related. Additionally, Droidium annotation would have default instrumentation port which could be specified manually and it will have two modes of operations: {code} @Droidium(mode = DroidiumType.NATIVE) // default mode @Droidium(mode = DroidiumType.WEB) {code} "Instrumenting" web deployment and running tests from Android device would eventually look like this: {code} @RunWith(Arquillian.class) @RunAsClient public class TestCase { @Droidium(type = DroidiumType.WEB) private WebDriver driver; @Deployment public static Archive<?> getJBossASDeployment() { return WAR } } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1756) wlp-managed arquillian support for wlp server assembly

by Gerhard Poul (JIRA)

[ https://issues.jboss.org/browse/ARQ-1756?page=com.atlassian.jira.plugin.s... ] Gerhard Poul commented on ARQ-1756: ----------------------------------- Thanks for opening this feature request! What would this feature do exactly? Do other arquillian adapters provide this function already? Please also look at the section at http://arquillian.org/guides/getting_started/#test_across_containers and see how this is documented to work for jboss-as artifacts. I think this should also work with Liberty. What do you think? > wlp-managed arquillian support for wlp server assembly > ------------------------------------------------------ > > Key: ARQ-1756 > URL: https://issues.jboss.org/browse/ARQ-1756 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: WebSphere Containers > Reporter: D K > > Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: > https://github.com/WASdev/ci.maven#liberty-assembly > It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. > https://github.com/arquillian/arquillian-container-was/tree/master/wlp-ma... > This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1756) wlp-managed arquillian support for wlp server assembly

by Gerhard Poul (JIRA)

[ https://issues.jboss.org/browse/ARQ-1756?page=com.atlassian.jira.plugin.s... ] Gerhard Poul updated ARQ-1756: ------------------------------ Assignee: (was: Gerhard Poul) > wlp-managed arquillian support for wlp server assembly > ------------------------------------------------------ > > Key: ARQ-1756 > URL: https://issues.jboss.org/browse/ARQ-1756 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: WebSphere Containers > Reporter: D K > > Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: > https://github.com/WASdev/ci.maven#liberty-assembly > It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. > https://github.com/arquillian/arquillian-container-was/tree/master/wlp-ma... > This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1557) Align undeployment logic in a proper Arquillian way

by Stefan Miklosovic (JIRA)

[ https://issues.jboss.org/browse/ARQ-1557?page=com.atlassian.jira.plugin.s... ] Stefan Miklosovic updated ARQ-1557: ----------------------------------- Fix Version/s: droidium_1.0.0.Beta1 > Align undeployment logic in a proper Arquillian way > --------------------------------------------------- > > Key: ARQ-1557 > URL: https://issues.jboss.org/browse/ARQ-1557 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha2 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Beta1 > > Attachments: brainstorming.jpg > > > Right now, undeployment logic for Droidium is bound to observer which observes with precedence -100 on AfterClass event in order to be sure that this observer will be treated as the latest one. > Right now, we have to be sure that undeployment logic is treated lastly in AfterClass since Arquillian Drone destroys WebDriver instances in AfterClass as well and the destruction of WebDriver instance, in our case, means that Selendroid server will be uninstalled from Android device. > Since the destruction of WebDriver instance itself is executed randomly in AfterClass regarding of execution time, we can not do undeployment of APKs on UnDeployDeployment event because when doing so, uninstallation of instrumented APK automatically kills Selendroid server process as well so that in turn means that subsequent trying to destroy WebDriver instance fails since Selendroid server is not running anymore and Drone talks to nobody. > To be sure that all Selendroid servers are uninstalled so we can proceed with the uninstallation of deployments, where it should be done, there has to be a guarantee that all WebDriver instances were already destroyed. > The solution here seems to be quite simple - we put some positive precedence for DroneDestructor (1) however by doing so, it could cause some backward compatibility issues with Drone extension. > (1) https://github.com/arquillian/arquillian-extension-drone/blob/master/dron... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1557) Align undeployment logic in a proper Arquillian way

by Stefan Miklosovic (JIRA)

[ https://issues.jboss.org/browse/ARQ-1557?page=com.atlassian.jira.plugin.s... ] Stefan Miklosovic resolved ARQ-1557. ------------------------------------ Resolution: Done https://github.com/arquillian/arquillian-droidium/tree/ARQ-1557 > Align undeployment logic in a proper Arquillian way > --------------------------------------------------- > > Key: ARQ-1557 > URL: https://issues.jboss.org/browse/ARQ-1557 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha2 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Beta1 > > Attachments: brainstorming.jpg > > > Right now, undeployment logic for Droidium is bound to observer which observes with precedence -100 on AfterClass event in order to be sure that this observer will be treated as the latest one. > Right now, we have to be sure that undeployment logic is treated lastly in AfterClass since Arquillian Drone destroys WebDriver instances in AfterClass as well and the destruction of WebDriver instance, in our case, means that Selendroid server will be uninstalled from Android device. > Since the destruction of WebDriver instance itself is executed randomly in AfterClass regarding of execution time, we can not do undeployment of APKs on UnDeployDeployment event because when doing so, uninstallation of instrumented APK automatically kills Selendroid server process as well so that in turn means that subsequent trying to destroy WebDriver instance fails since Selendroid server is not running anymore and Drone talks to nobody. > To be sure that all Selendroid servers are uninstalled so we can proceed with the uninstallation of deployments, where it should be done, there has to be a guarantee that all WebDriver instances were already destroyed. > The solution here seems to be quite simple - we put some positive precedence for DroneDestructor (1) however by doing so, it could cause some backward compatibility issues with Drone extension. > (1) https://github.com/arquillian/arquillian-extension-drone/blob/master/dron... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1536) Provide @StartActivity annotation put on test method to automatically start it or use @Location from Graphene to do so

by Stefan Miklosovic (JIRA)

[ https://issues.jboss.org/browse/ARQ-1536?page=com.atlassian.jira.plugin.s... ] Stefan Miklosovic resolved ARQ-1536. ------------------------------------ Resolution: Done Implemented directly in Graphene as ARQGRA-408 and merged to 2.1.x stream. Resolving as done, marking as closed once Droidium depends on Graphene on 2.1.x version. > Provide @StartActivity annotation put on test method to automatically start it or use @Location from Graphene to do so > ---------------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1536 > URL: https://issues.jboss.org/browse/ARQ-1536 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha2 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > > Instead of starting activity every time in test method manually, it would be nice to have this possibility: > {code} > @Test > @InSequence(4) > @OperateOnDeployment("todo-mobile-app") > public void loginUserInMobile(@ArquillianResource AndroidDevice device) { > device.getActivityManagerProvider() > .getActivityManager() > .startActivity("org.jboss.aerogear.todo.activities.LoginActivity"); > loginMobileFragment.login("john", "123"); > } > ========================= > @Test > @InSequence(4) > @OperateOnDeployment("todo-mobile-app") > @StartActivity("org.jboss.aerogear.todo.activities.LoginActivity") > public void loginUserInMobile() { > loginMobileFragment.login("john", "123"); > } > {code} > However, with the possibility to have Graphene page fragments, it would be teoretically possible to have propper page objects as well which mean that we could abstract activity into @Page and specify its @Location("activityName") > The problem is, how this translates to Graphene since Droidium starts activities in this manner: > driver.get("and-activity://" + activityName); > There is the need to take that "and-activity" string into consideration with @Location annotation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1528) Be able to start multiple Android containers simultaneously in one test run

by Stefan Miklosovic (JIRA)

[ https://issues.jboss.org/browse/ARQ-1528?page=com.atlassian.jira.plugin.s... ] Stefan Miklosovic updated ARQ-1528: ----------------------------------- Priority: Blocker (was: Major) > Be able to start multiple Android containers simultaneously in one test run > --------------------------------------------------------------------------- > > Key: ARQ-1528 > URL: https://issues.jboss.org/browse/ARQ-1528 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Priority: Blocker > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1528) Be able to start multiple Android containers simultaneously in one test run

by Stefan Miklosovic (JIRA)

[ https://issues.jboss.org/browse/ARQ-1528?page=com.atlassian.jira.plugin.s... ] Stefan Miklosovic updated ARQ-1528: ----------------------------------- Issue Type: Feature Request (was: Enhancement) > Be able to start multiple Android containers simultaneously in one test run > --------------------------------------------------------------------------- > > Key: ARQ-1528 > URL: https://issues.jboss.org/browse/ARQ-1528 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha1 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Priority: Blocker > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1753) Support multiple devices

by Stefan Miklosovic (JIRA)

[ https://issues.jboss.org/browse/ARQ-1753?page=com.atlassian.jira.plugin.s... ] Stefan Miklosovic closed ARQ-1753. ---------------------------------- Resolution: Duplicate Issue I believe this issue is duplicate of ARQ-1528 reported long time ago. > Support multiple devices > ------------------------ > > Key: ARQ-1753 > URL: https://issues.jboss.org/browse/ARQ-1753 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha5 > Reporter: Karel Piwko > Priority: Blocker > > Droidium does not support multiple devices. > If you try to specify two containers in a group, both Droidium native, the configuration of the first one is ignored and only one is started. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues April 2014