1 Reply Latest reply on Oct 2, 2013 2:33 AM by kpiwko

    What should be the next Droidium extension?

    smikloso

      Hi,

       

      I would like to have some minipoll here regarding Droidium.I know it is pretty soon to develop something else except core bits when there is not even Final out but anyway ... Since these extensions are kind of important and rather demanding regarding of time to spend on them and implement them as well, I would like to have your opinion what is really necessary to have in order to move this whole project forward.


      1) Arquillian Droidium grid


      Imagine you have 10 devices you want to do the tests on. Well, it does not need to be some test. Lets say that you just need to see how every device is doing comparing to each other. There could be one WebDriver instance and some proxy so when you execute command on WebDriver / Drone or in one Android container in general, it will be handled by that proxy which in turn sends that call to all Android devices. The problem is with the response since every phone / emulator could sent something different. Or you want to install 1 package to 10 devices simultaneously and then you need to do the same thing on all of them and see how they are doing. That would be this extension good for ...


      2) Arquillian platform support


      It would be possible to download and  build resources as whole Android SDKs, selendroid servers, android servers for Selenium .... you name it ... directly in the test itself. This is rather hard to imagine but lets say that you have pure pc (no android sdk, nothing) and with this extension, it would be automatically downloaded and boostrapped so you can just proceed with tests. You can go even further and e.g. when you detect there is not selendroid server on the class path, it downloads it from repo (github) and it builds that project and resulting apk is prepare to be used ... sky is the limit but you have the picture what it would be good for ... When you are doing tests with Droidium, you let a user to download all apks which is not really convenient. There should be some defaults so even it is not present in the project (that required apk), it should be possible to download that dynamically and build it from Maven Central and so on ...


      3) Arquillian Droidium Unit


      True native unit testing, not just web and native (functional) + ShrinkWrap support for Android archives, it would be _great_ to have that extension and it would be kind of intergalactically awesome. There would be Droidium for everything. Swiss army knife for testing Androids. There would be nothing what Droidium could not cover.


      4) Container for iOS


      The same way Android container is developed, it should be possible to implement container of iOS. The problem is that even there are some experiments with this, it is only extension and it is quite old. The next big question is if we expect to write iOS developer tests in Java ... I guess that is not the case. He would stick with Objective-C or what ... Maybe we should wait here for Arq 2.0?


      5)

       

      And the last one ... is kind of funny. The whole principle is that your tests would be written automatically. Lets say that you have web page + android. Right now, what you are going to do is to open up firebug and you try to map WebElements with FindBy and so on. Maybe I am totally naive here and it is stupid, but when you can click on certain position and you getLocation, could not that be done otherwise? So you click on the page and you get ID of the element you clicked. That is pretty the same scenario when you are actually interacting with the site.

       

      The main "feature" would be to start arquillian in kind of debug / monitor mode. All deployments would be deployed and so on but that test itself would be kind of fakeish and it would stop so you can click around the page, pretending you are user, actually "doing / clicking" the real test scenario. After this, these elements and their clicks would be translated / transformated into ordinary java source code so you would have pretty much resources to start with + the main "logic" of the testcase would be done as well, you just have to write your asserts basically ... it would be very nice as a starting point, I personally hates to search for some ids a/ jquery locators / xpath / css locators all the time, that extension would do that for me ...

       

      this would construct classes: http://spoon.gforge.inria.fr/

      this would check the element just clicked: http://stackoverflow.com/questions/1259585/get-element-at-specified-position-javascript

       

      I am really not too much into JavaScript but I think there is JavaScriptExecutor and that kind of stuff, that could help, could not?

       

      Thanks! Do not hesitate to do your own ideas. Feel free do add yours to comments.


      I wanted to add regular poll widget but I was not able to add it to this "space", it is greyed out. Could somebody confirm this? I think there is some priviledge missing in my case but dunno otherwise ...

       

      Message was edited by: Stefan Miklosovic

        • 1. Re: What should be the next Droidium extension?
          kpiwko

          My personal opinion is 2) should have the biggest priority from the list. Together with making setup easier. I think Droidium should focus on making its usage as simple as possible, without limited possibilities of hiccups.

           

          As long as Droidium is super easy to be used, I'd proceed with 3). As for the 5), is this about creating a project like Selenium IDE? There are plenty of projects like that already, so I think people willing to record their test will have no reason to use Droidium, as you can't record where it really excels - combining multiple testing approaches, clients and servers together.