I'm currently using ARC to manually test my app, but am hoping to move towards automation of the testing process.
Is it possible to use ARC to automate tests, something similar to what Selenium Webdriver does for FF/Chrome?
I know it's still early in the development process but something like this would be incredibly helpful.
Yes. ARC supports the Android adb "shell instrument" command, per the Android documentation
See the Getting Started document for starting adb.
If you create an .apk for the tests that is separate from the .apk being tested, you will need to bundle both .apk files together in the .crx package. It should be straightforward to incorporate doing that and launching the tests into any build/test environment.
Related
As I can see here you need OS X to build apps with React Native. That is probably because they used it at first to create only iOS apps. Now it's possible to create Android apps with React Native but they still require OS X as development platform which doesn't make sense to me. Is there any way to create Android apps using React Native on Ubuntu OS or any other Linux?
Update 2: I've been developing React native apps on Ubuntu for some time now, without any issues.
Update 1: It's almost possible on linux and windows now. Check this doc page: link
Old answer:
It's already almost working, from the issue shared in kzzzf's answer:
Everything works on Linux except:
react-native run-android can't open a new shell window, you need to
use react-native start. Will be fixed in next release. Debugging in
Chrome currently relies on an AppleScript to launch Chrome. There's a
PR to replace that.
Building on linux and windows is not officially supported although there are people in the community already sending pull requests that will allow to do so (main obstacle is the fact of using apple-script and calling to shell scripts from node - from react-packager and from react-cli).
Main task for tracking those efforts is here: https://github.com/facebook/react-native/issues/2693
While it's not officially supported on Linux yet, and there are certainly some hoops to jump through, I have created a docker container that allows me to build and run android apps from Ubuntu.
The dockerfile is still a work in progress but it's available on github: https://github.com/gilesp/docker/tree/master/react_native
There's a couple of shell scripts to make local development easier - I mainly use the react-bash script to give me a shell prompt in the container for running react-native run-android etc.
It works well enough that I can have a phone connected via USB on my host machine, the react native stuff running in the container and have my edits to the code (I mainly edit using emacs on the host) appear immediately on the device.
I'm currently working on CI builds for android as there are some more hoops to jump through to create the bundled version of the javascript for deployment.
It should be possible by now. For an up to date guide on "can i build for platform X on system Y", see:
https://facebook.github.io/react-native/docs/getting-started.html
I have already finish most of the code of the robotium testing which is running on the android studio. I am just wondering which is the most effective way to make a release? To make a jar(how to do that)? Or make a interface? Because the QA team do not want to code so I have to make a platform which well organize without any code.
You always may launch your tests from the command line with adb
adb shell am instrument -w yourproject.com/android.test.InstrumentationTestRunner
However I would recommend you take a look on the Spoon project that may help with the test instrumentation and distribution.
In android I am working on JUNIT test cases which are working fine on emulator and device, but I just want to know that how I can run test case in the absence of emulator and device.
Is their any way to execute android test cases without using emulator and device?
Any reference link or point of information will be help full for me.
Thanks in advance.
If you have the newest version of Android Studio, it should allow you to run the junits without the emulator or device, so long as those junits are not dependent on having the emulator/device running.
It is important to put the junit test files in the app/src/test/java/[apk_package]/ folder, not the app/src/androidTest/java/[apk_package]/ folder! Putting it in the androidTest folder will force run the android emulator or device runner.
This is what Robolectric is designed for. In my limited use its quite good but be warned: they're in between major releases and accurate documentation is pretty sparse.
It's known you can run Python on Android with QPython, but first users have to download and install it on their phone.
Just wondering: is it possible to pack QPython dependencies together with "app" script creating a "standalone" PlayStore-ready .apk?
It's not a direct answer to your question, but you can create totally standalone apks with the graphical framework kivy, or specifically kivy's android build tools. They only directly support apps with a kivy gui, but this is easy to construct if you just want to run a simple script.
Alternatively, I think you actually only need to put your code in a kivy App class, which will run the script but then immediately exit if you don't define any graphics. Maybe this is exactly what you want.
I am doing a little research on how to setup Continuos delivery pipeline for Android apps. I am aware of existing approaches of using Jenkins and Ant scripts for making a build. What I'd really like to do is when I do a git push on say a development branch, I'd like Jenkins to do a build on bunch of emulators (With different resolutions) run my Robotium scripts and email me results.
I am looking for end-to-end setup preferably the server would run on Ubuntu.
Siddharth,
You may want to consider CloudMunch for this need. All you need to do is launch the emulators as part your pipeline to test various stacks and finally get an update over mail. Robotium scripts can be called over shell and reports will come to you as mail at the end of the test.