Really cool! Good work! I gave it a test run. It was really quick to setup and is super powerful, muuuuch better than standard instrumentation. If anyone is interested you can see a basics tutorial I put together here: http://www.stevenmarkford.com/android-ui-testing-with-espresso-basics-tutorial/
UIAutomator has its place, UIAutomator is really cool for system-wide integration tests. e.g. turning settings on and off while testing app in particular system state, it is pretty powerful in that way. Where as Espresso seems to shine when needing to do neat little test runs per activity.
Alright. I use UIAutomator fairly extensively; are there any plans to integrate Expresso functionality with UIAutomator? UIAutomator, while very powerful, is terribly unwieldy for simple tasks. Expresso appears to be capable to fast and quick 'click' actions and the like within activities. Obviously, you could just implement a script to call a UIAutomator Watcher and engage an Expresso action in order to "combine" them, but I am wondering if these frameworks could be complementary rather than parallel.
Screenshots are outside the scope of Espresso, but there are solutions out there. Take a look at the discussion here: https://groups.google.com/forum/#!searchin/android-test-kit-discuss/screenshot/android-test-kit-discuss/Fc-yVCedwAg/oXeXJEEB_0oJ
What's the best way to get sound options on the advanced power menu i.e. the ability to have sound/mute/vibrate options when you hold down the power key. This is missing.
Togging system settings is outside the scope of Espresso. Internally, we have a utility that tests can call into for setting up such state. We will be looking into open sourcing this in the future.
I put here a 5 minuts set up of Espresso in Android Studio projects together with the Github link to the working example: https://medium.com/p/c476d3b5ba45
Espresso is what I've been hoping for! For Gradle users, Jake Wharton provided a way to import Espresso via Gradle. https://github.com/JakeWharton/double-espresso
Thanks for this awesome testing-framework! TestObject does also have support for Espresso on real devices: https://testobject.com/features/automation Disclaimer: I'm co-founder of TestObject.
I wrote a blog post describing our experiences testing Android apps with Robolectric and Double Espresso in Gradle here: https://engineering.aweber.com/avoiding-robolectric-shock-while-testing-android-with-gradle-and-espresso/
I am trying to have multiple @Test annotations with each test being a continuation from the previous screen. ex : From home page -> Do a search -> Click a search result et
However @Rule cause the MainActivity to launch each time.
How can I maintain the flow of my test without having to launch Main activity before each test.
Look forward to giving this a go!
ReplyDeleteReally cool! Good work! I gave it a test run. It was really quick to setup and is super powerful, muuuuch better than standard instrumentation. If anyone is interested you can see a basics tutorial I put together here: http://www.stevenmarkford.com/android-ui-testing-with-espresso-basics-tutorial/
ReplyDeleteIt's not easy to setup, it takes 2 engineers for one week to conclude we may change to Robotium..
DeleteSo, is this framework intended to replace the UIAutomator framework? Or is it used just as a quick-and-easy UI test scripting set?
ReplyDeleteUIAutomator has its place, UIAutomator is really cool for system-wide integration tests. e.g. turning settings on and off while testing app in particular system state, it is pretty powerful in that way. Where as Espresso seems to shine when needing to do neat little test runs per activity.
DeleteAlright. I use UIAutomator fairly extensively; are there any plans to integrate Expresso functionality with UIAutomator? UIAutomator, while very powerful, is terribly unwieldy for simple tasks. Expresso appears to be capable to fast and quick 'click' actions and the like within activities. Obviously, you could just implement a script to call a UIAutomator Watcher and engage an Expresso action in order to "combine" them, but I am wondering if these frameworks could be complementary rather than parallel.
DeleteIs it possible to take screenshots?
ReplyDeleteScreenshots are outside the scope of Espresso, but there are solutions out there. Take a look at the discussion here: https://groups.google.com/forum/#!searchin/android-test-kit-discuss/screenshot/android-test-kit-discuss/Fc-yVCedwAg/oXeXJEEB_0oJ
DeleteWhat's the best way to get sound options on the advanced power menu i.e. the ability to have sound/mute/vibrate options when you hold down the power key. This is missing.
ReplyDeleteandroid
Togging system settings is outside the scope of Espresso. Internally, we have a utility that tests can call into for setting up such state. We will be looking into open sourcing this in the future.
DeleteYou can also try Espresso on real devices at Testdroid Cloud. Only 3 steps and instructions can be found here:
ReplyDeletehttp://testdroid.com/testdroid/6384/how-to-run-espresso-tests-in-testdroid-cloud
I put here a 5 minuts set up of Espresso in Android Studio projects together with the Github link to the working example: https://medium.com/p/c476d3b5ba45
ReplyDeleteEspresso is what I've been hoping for! For Gradle users, Jake Wharton provided a way to import Espresso via Gradle. https://github.com/JakeWharton/double-espresso
ReplyDeleteThanks for this awesome testing-framework! TestObject does also have support for Espresso on real devices: https://testobject.com/features/automation
ReplyDeleteDisclaimer: I'm co-founder of TestObject.
I wrote a blog post describing our experiences testing Android apps with Robolectric and Double Espresso in Gradle here: https://engineering.aweber.com/avoiding-robolectric-shock-while-testing-android-with-gradle-and-espresso/
ReplyDeleteHi,
ReplyDeleteIs there any tutorials helping to write espresso test cases for accessibility checking? Thanks!
I am trying to have multiple @Test annotations with each test being a continuation from the previous screen. ex : From home page -> Do a search -> Click a search result et
ReplyDeleteHowever @Rule cause the MainActivity to launch each time.
How can I maintain the flow of my test without having to launch Main activity before each test.