less pain full testing automation tool doc extra
TRANSCRIPT
Lesspainfull testing automation tool
Documentation
New to LessPainful.com?
If you're new to LessPainful you might want to start with the tutorial.
How it works
Thoroughly testing is an important step in creating quality applications but in a world with over a hundred different Android devices this can be a costly affair. But what if you could write tests and have them run automatically on a wide range of devices?
Here's how it works:
1. Write your application and tests 2. Upload both to us 3. We hand it off to our robotic minions and the tests run on real phones 4. Review the test results
Real devices
Your application and tests are run on physical devices of your choosing.There's no cheating and no shortcuts. Just real physical Android devices.
Easy
Tests are written in Cucumber making for tests that are easy to write and easy to read. See an example. See the Writing tests section for more information on how to write tests.
Comparative results
And the result you'll get will help you to quickly spot errors and inconsistencies across devices, so you get to focus on correcting problems and not on finding them.See the annotated example test report for an in depth look.
Got Questions?
Feel free to contact us: [email protected] / twitter
Writing tests
As stated above the tests are written in Cucumber We provide a set of steps for you to use when writing the tests. We'll go into further details in the next section, but we'll start with an example (skip ahead if you already know Cucumber).
An example
All the examples will tests the "LessPainful (but mostly useless) companion" app. You can find a the app here if you want a closer look at the code.
Below is an example of the sort of tests you'll be writing when using LessPainful. Tests are structured in features and each feature consists of one or more scenarios. In the example below we'll test the "Steps guide" feature of the example app and more specifically we'll be testing the scenario where the user wants to see an explanation of the "And I enter "[some text]" as "[some input field]"" step.
Feature: Handy pocket guide to the LessPainful step definitions In order to better understand how to enter text into input fields As a LessPainful customer I want to see how some of the available test steps and take a closer look at one Scenario: Open a step definition from the steps list Given my app is running And I wait for "The LessPainful (but mostly useless) companion" to appear Then take picture Then I press the menu key Then take picture And I select "Steps" from the menu Then take picture And I wait for "Enter text into input field" to appear And I select "Enter text into input field"
And I wait for "Step definition" to appear Then take picture
You can put whatever you like in the Feature and Scenario lines but you should strive for tests that would makes sense for anyone who knows your app.
All scenarios must start with "Given my app is running".The next thing that happens is that we wait for the text "The LessPainful (but mostly useless) companion" to appear. Your tests are going to have to handle timing issues, and waiting for texts
or buttons to appear is the best way of doing this (see Handling timing issues) for more on this. We then press the phones menu key and take a picture.
Try and start the example app and see if you can follow the test description by hand. You should strive to make tests as easily understandable as possible because it helps maintainability.
Limitations
Beneath it all we're actually running ActivityInstrumentationTestCase2 and they come with one big limitation. You cannot test across applications. You can test across multiple Activities in you own application. But the moment you step out of you own application (eg. by starting an intent not in you AndroidManifest) the party stops. You can still take a picture though.
Also you should not rely on any specific application to be installed on the phone. We try to keep our phones as close to factory settings as we can and so we don't install additional applications.
Available test steps
Steps are the atomic unit in cucumber test and they are what drives the test. LessPainful supplies a set of predefined steps you can use. We'll go trough these in detail in the following section.
If you find that you need to do something that cannot be done with the steps already defined then let us know: [email protected] / twitter
Reading the step definitions
Cucumber defines a set of keywords: Given, When, Then, But or And. These go before any step in your tests, we don't treat them differently but that does not mean you shouldn't. So for example to take a picture at some point you could write:Given take picture When take picture Then take picture But take picture And take picture
We don't think you should use the forms we have marked with strike trough but we won't stop you
The most of the steps below contain regular expression. There is one that allows you to enter text: ([^\"]*) meaning that you can enter text here.For example:And I press the "Login" button
And one that allows you to enter integers (whole numbers): (\d+)For example:Then I press button number 3
Pressing buttons
Below is given the steps that are available for pressing the buttons and views in you app. Before you start using first a few words on how we find out which buttons/views to press. If you are using one of the press button steps we resolve them in the following way:
1. Button text: We try to find a button with the text given in the step (eg. "Login").
2. Content description:If the above fails we then look at content descriptions (eg. what you supply to setContentDescription() in you app).
3. Class name:If all else fails we try to find a class with the name you supplied. We only look at the class name not the fully qualified class name
If we cannot find a button the step fails and we supply a list of what we could find in the test report When using steps that try to target Views (and not just buttons) only content descriptions are used. We are case-insensitive when resolving elements (this goes for all types of Views)
Step definitions
Step: /^I click on screen (\d+)% from the left and (\d+)% from the top$/
Description:Performs a short press at a arbitrary position on the screen. This step should be considered a last resort as it isn't very robust
Step: /^I press "([^\"]*)"$/
Description: Tries to press a button or view. Tries to press buttons first, then tries all View typesStep: /^I press button number (\d+)$/
Description:The button with the matching index is pressed. Using this step leads to less readable test so use sparingly.Buttons are zero indexed.
Step: /^I press the "([^\"]*)" button$/
Description: Presses the button with the matching text, content description or classnameStep: /^I press view with name "([^\"]*)"$/
Description: Presses a View with the matching content descriptionStep: /^I press image button number (\d+)$/
Description:The image button with the matching index is pressed. Using this step leads to less readable test so use sparingly.Buttons are zero indexed.
Step: /^I press list item number (\d+)$/
Description:Pressed the specified line in the first list visble liste. List items are one indexed.
Step: /^I toggle checkbox number (\d+)$/
Description: Toggles the checkbox with the matching index.
Checkboxes are zero indexed. Step: /^I touch the "([^\"]*)" text$/
Description: Tries to find the supplied text and press it.Step: /^I long press "([^\"]*)"$/
Description: Long presses the supplied text.Step: /^I long press "([^\"]*)" and select "([^\"]*)"$/
Description:Long presses the text supplied as first argument. Then selects a item from the context menu matching the second argument
Step: /^I long press "([^\"]*)" and select item number "([^\"]*)"$/
Description:Long presses the text supplied as first argument. Then selects a item from the context menu matching index given as second argument
Entering text
Below is given the steps that are available for entering text into you app (EditTexts to be specific).When resolving we look only at Content descriptions (or index for one step).
Step:/^I enter "([^\"]*)" as "([^\"]*)"$//^I enter "([^\"]*)" into "([^\"]*)"$/
Description:Enters the first supplied argument into the EditText with a content description matching second argument
Step: /^I enter "([^\"]*)" into input field number (\d+)$/
Description: Enters the first argument into the EditText with the supplied index.Step: /^I clear "([^\"]*)"$/
Description: Clears the text from the EditText with matching Content descriptionStep: Then /^I clear input field number (\d+)$/
Description: Clears the text from the EditText with matching index
Waiting for progress
Your tests need to be robust in regards to timing issues or your tests become flaky.The best way of doing this is waiting for a specific condition to occur. The steps below help to achieve that. We also supply steps for waiting a specific amount of time, but we don't recommend using those.
Step: /^I wait for "([^\"]*)" to appear$/
Description: Waits until the supplied text appears on screen. Timesout after 30 secondsStep: /^I wait for (\d+) seconds$/
Description: Waits for the supplied amount of secondsStep: /^I wait for dialog to close$/
Description: Waits for a dialog to closeStep: /^I wait for progress$/
Description: Waits for there to be no progress bars
Step: /^I wait for the "([^\"]*)" button to appear$/
Description: Waits for a Button/ImageButton with the supplied text/content description to appearStep: /^I wait$/
Description: Waits for 2 seconds
Navigation
These steps provided steps for common navigation actions.
Step: /^I go back$/
Description: Presses the phones "back" buttonStep: /^I select "([^\"]*)" from the menu$/
Description: Selects the suplied menu itemStep: /^I swipe left$/
Description: Makes a swiping gesture to the leftStep: /^I swipe right$/
Description: Makes a swiping gesture to the rightStep: /^I scroll down$/
Description: Makes a single scrolling gesture
Assertions
Assertions are used to, well assert things.
Step:/^I dont see the text "([^\"]*)"$/
/^I dont see the "([^\"]*)"$/ Description: Tries to find the supplied text on screen. Fails if it finds it
Step:/^I see the text "([^\"]*)"$/
Then /^I see the "([^\"]*)"$/ Description: Tries to find the supplied text on screen. Fails if it does not find it.
Date and Time pickers
These steps allow you to set the values of Date- and TimePickers
Step:/^I set the date to "(\d\d-\d\d-\d\d\d\d)" on DatePicker with index "([^\"]*)"$/
Description:Enters the supplied date into the DatePicker with the given index. The first argument is the date. The date format is (dd-MM-yyyy). Second argument is the index
Step: /^I set the "([^\"]*)" date to "(\d\d-\d\d-\d\d\d\d)"$/
Description:Enters the supplied date into the DatePicker with the given content description. The first argument is the content description.The second argument is the date. The date format is (dd-MM-yyyy).
Step:/^I set the time to "(\d\d:\d\d)" on TimePicker with index "([^\"]*)"$/
Description:Enters the supplied time into the TimePicker with the given index. The first argument is the time. The time format is (HH:mm). Second argument is the index
Step: /^I set the "([^\"]*)" time to "(\d\d:\d\d)"$/
Description:Enters the supplied date into the DatePicker with the given content description. The first argument is the content description.The second argument is the time. The time format is (HH:mm).
Setting locations
Sometimes you might want to test location aware parts of your application. You can use the following steps to persuade the phones that they are in some location of your choice.Please notice that you need to set the ACCESS_MOCK_LOCATION along with ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION to use these steps.
Step:/^I am in "([^\"]*)"$//^I am at "([^\"]*)"$/
/^I go to "([^\"]*)"$/
Description:Sets the phones gps location based on the given string. When the test is running the string is translated into a gps coordinate using Google's geocoding api
Step:/^I am at ([-+]?[0-9]*\.?[0-9]+), ([-+]?[0-9]*\.?[0-9]+)$//^I to to ([-+]?[0-9]*\.?[0-9]+), ([-+]?[0-9]*\.?[0-9]+)$/
Description: Sets the phones gps location to the given coordinate. (latitude, longitude)
Taking pictures
This is the step that allows you to take screenshots of the app in its current state.
Step: /^take picture$/
Description: Allows you to take a screenshot of the app in its current state. Remember: Your scenarios must start with the /^my app is running$/ step
Handling timing issues
You want your tests to be robust and timing issues is one of the most common root causes for flaky tests. Waiting for a specific amount of time is bad (but possible) but is bound to end in tears. Waiting for a specific condition is great. eg. wait for a button before pressing it, waiting for a specific text that indicates that the next activity has started.
Command-line accces
What is the fun of writing automatic tests if you then have to login to a web page to actually run them?Well luckily you will not have to because you can start them from the command-line.
Starting tests
First of all make sure you have set up a user secret for your project. You can find it under My Projects › [your project] › Secrets. Got it? We'll be using cURL so make sure you have that as well.
Then all you have to do is thiscurl -F "secret=[your_secret]" -F "app=@[path to your Android app]" -F "test[]=@[path to a test]" -F "test[]=@[path to another test]" http://www.lesspainful.com/cmd_upload
Lets break that down a little:
-F "secret=[your_secret]" is where you supply your user secret (without the '[' and ']' show here but with the quotes). -F "app=@[path to your Android app]". Insert the path (on you local file system) to your .apk file -F "test[]=@[path to a test]". Insert the path (on you local file system) to a .feature test file. You can upload as many feature files as you wish
Test status
After starting a test you can access its status by issuing this command:curl -F "secret=[your_secret]" -F "id=[test_id]"
http://www.lesspainful.com/cmd_status test_id is the id returned when you started the test.If you don't provide an id you will get back the status of the last ten tests.
Documentation
New to LessPainful.com?
If you're new to LessPainful you might want to start with the tutorial.
How it works
Thoroughly testing is an important step in creating quality applications but in a world with over a hundred different Android devices this can be a costly affair. But what if you could write tests and have them run automatically on a wide range of devices?
Here's how it works:
1. Write your application and tests 2. Upload both to us 3. We hand it off to our robotic minions and the tests run on real phones 4. Review the test results
Real devices
Your application and tests are run on physical devices of your choosing.There's no cheating and no shortcuts. Just real physical Android devices.
Easy
Tests are written in Cucumber making for tests that are easy to write and easy to read. See an example. See the Writing tests section for more information on how to write tests.
Comparative results
And the result you'll get will help you to quickly spot errors and inconsistencies across devices, so you get to focus on correcting problems and not on finding them.See the annotated example test report for an in depth look.
Got Questions?
Feel free to contact us: [email protected] / twitter
Writing tests
As stated above the tests are written in Cucumber We provide a set of steps for you to use when writing the tests. We'll go into further details in the next section, but we'll start with an example (skip ahead if you already know Cucumber).
An example
All the examples will tests the "LessPainful (but mostly useless) companion" app. You can find a the app here if you want a closer look at the code.
Below is an example of the sort of tests you'll be writing when using LessPainful. Tests are structured in features and each feature consists of one or more scenarios. In the example below we'll test the "Steps guide" feature of the example app and more specifically we'll be testing the scenario where the user wants to see an explanation of the "And I enter "[some text]" as "[some input field]"" step.
Feature: Handy pocket guide to the LessPainful step definitions In order to better understand how to enter text into input fields As a LessPainful customer I want to see how some of the available test steps and take a closer look at one Scenario: Open a step definition from the steps list Given my app is running And I wait for "The LessPainful (but mostly useless) companion" to appear Then take picture Then I press the menu key Then take picture And I select "Steps" from the menu Then take picture And I wait for "Enter text into input field" to appear And I select "Enter text into input field"
And I wait for "Step definition" to appear Then take picture
You can put whatever you like in the Feature and Scenario lines but you should strive for tests that would makes sense for anyone who knows your app.
All scenarios must start with "Given my app is running".The next thing that happens is that we wait for the text "The LessPainful (but mostly useless) companion" to appear. Your tests are going to have to handle timing issues, and waiting for texts or buttons to appear is the best way of doing this (see Handling timing issues) for more on this. We then press the phones menu key and take a picture.
Try and start the example app and see if you can follow the test description by hand. You should strive to make tests as easily understandable as possible because it helps maintainability.
Limitations
Beneath it all we're actually running ActivityInstrumentationTestCase2 and they come with one big limitation. You cannot test across applications. You can test across multiple Activities in you own application. But the moment you step out of you own application (eg. by starting an intent not in you AndroidManifest) the party stops. You can still take a picture though.
Also you should not rely on any specific application to be installed on the phone. We try to keep our phones as close to factory settings as we can and so we don't install additional applications.
Available test steps
Steps are the atomic unit in cucumber test and they are what drives the test. LessPainful supplies a set of predefined steps you can use. We'll go trough these in detail in the following section.
If you find that you need to do something that cannot be done with the steps already defined then let us know: [email protected] / twitter
Reading the step definitions
Cucumber defines a set of keywords: Given, When, Then, But or And. These go before any step in your tests, we don't treat them differently but that does not mean you shouldn't. So for example to take a picture at some point you could write:Given take picture When take picture Then take picture But take picture And take picture
We don't think you should use the forms we have marked with strike trough but we won't stop you
The most of the steps below contain regular expression. There is one that allows you to enter text: ([^\"]*) meaning that you can enter text here.For example:And I press the "Login" button
And one that allows you to enter integers (whole numbers): (\d+)For example:Then I press button number 3
Pressing buttons
Below is given the steps that are available for pressing the buttons and views in you app. Before you start using first a few words on how we find out which buttons/views to press. If you are using one of the press button steps we resolve them in the following way:
1. Button text: We try to find a button with the text given in the step (eg. "Login").
2. Content description:If the above fails we then look at content descriptions (eg. what you supply to setContentDescription() in you app).
3. Class name:If all else fails we try to find a class with the name you supplied. We only look at the class name not the fully qualified class name
If we cannot find a button the step fails and we supply a list of what we could find in the test report When using steps that try to target Views (and not just buttons) only content descriptions are used. We are case-insensitive when resolving elements (this goes for all types of Views)
Step definitions
Step: /^I click on screen (\d+)% from the left and (\d+)% from the top$/
Description:Performs a short press at a arbitrary position on the screen. This step should be considered a last resort as it isn't very robust
Step: /^I press "([^\"]*)"$/
Description: Tries to press a button or view. Tries to press buttons first, then tries all View typesStep: /^I press button number (\d+)$/
Description:The button with the matching index is pressed. Using this step leads to less readable test so use sparingly.Buttons are zero indexed.
Step: /^I press the "([^\"]*)" button$/
Description: Presses the button with the matching text, content description or classnameStep: /^I press view with name "([^\"]*)"$/
Description: Presses a View with the matching content descriptionStep: /^I press image button number (\d+)$/
Description:The image button with the matching index is pressed. Using this step leads to less readable test so use sparingly.Buttons are zero indexed.
Step: /^I press list item number (\d+)$/
Description:Pressed the specified line in the first list visble liste. List items are one indexed.
Step: /^I toggle checkbox number (\d+)$/
Description:Toggles the checkbox with the matching index.Checkboxes are zero indexed.
Step: /^I touch the "([^\"]*)" text$/
Description: Tries to find the supplied text and press it.Step: /^I long press "([^\"]*)"$/
Description: Long presses the supplied text.Step: /^I long press "([^\"]*)" and select "([^\"]*)"$/
Description:Long presses the text supplied as first argument. Then selects a item from the context menu matching the second argument
Step: /^I long press "([^\"]*)" and select item number "([^\"]*)"$/
Description:Long presses the text supplied as first argument. Then selects a item from the context menu matching index given as second argument
Entering text
Below is given the steps that are available for entering text into you app (EditTexts to be specific).When resolving we look only at Content descriptions (or index for one step).
Step:/^I enter "([^\"]*)" as "([^\"]*)"$//^I enter "([^\"]*)" into "([^\"]*)"$/
Description:Enters the first supplied argument into the EditText with a content description matching second argument
Step: /^I enter "([^\"]*)" into input field number (\d+)$/
Description: Enters the first argument into the EditText with the supplied index.Step: /^I clear "([^\"]*)"$/
Description: Clears the text from the EditText with matching Content descriptionStep: Then /^I clear input field number (\d+)$/
Description: Clears the text from the EditText with matching index
Waiting for progress
Your tests need to be robust in regards to timing issues or your tests become flaky.The best way of doing this is waiting for a specific condition to occur. The steps below help to achieve that. We also supply steps for waiting a specific amount of time, but we don't recommend using those.
Step: /^I wait for "([^\"]*)" to appear$/
Description: Waits until the supplied text appears on screen. Timesout after 30 secondsStep: /^I wait for (\d+) seconds$/
Description: Waits for the supplied amount of secondsStep: /^I wait for dialog to close$/
Description: Waits for a dialog to closeStep: /^I wait for progress$/
Description: Waits for there to be no progress barsStep: /^I wait for the "([^\"]*)" button to appear$/
Description: Waits for a Button/ImageButton with the supplied text/content description to appearStep: /^I wait$/
Description: Waits for 2 seconds
Navigation
These steps provided steps for common navigation actions.
Step: /^I go back$/
Description: Presses the phones "back" buttonStep: /^I select "([^\"]*)" from the menu$/
Description: Selects the suplied menu itemStep: /^I swipe left$/
Description: Makes a swiping gesture to the leftStep: /^I swipe right$/
Description: Makes a swiping gesture to the rightStep: /^I scroll down$/
Description: Makes a single scrolling gesture
Assertions
Assertions are used to, well assert things.
Step:/^I dont see the text "([^\"]*)"$/
/^I dont see the "([^\"]*)"$/ Description: Tries to find the supplied text on screen. Fails if it finds it
Step:/^I see the text "([^\"]*)"$/
Then /^I see the "([^\"]*)"$/ Description: Tries to find the supplied text on screen. Fails if it does not find it.
Date and Time pickers
These steps allow you to set the values of Date- and TimePickers
Step:/^I set the date to "(\d\d-\d\d-\d\d\d\d)" on DatePicker with index "([^\"]*)"$/
Description:Enters the supplied date into the DatePicker with the given index. The first argument is the date. The date format is (dd-MM-yyyy). Second argument is the index
Step: /^I set the "([^\"]*)" date to "(\d\d-\d\d-\d\d\d\d)"$/
Description:Enters the supplied date into the DatePicker with the given content description. The first argument is the content description.The second argument is the date. The date format is (dd-MM-yyyy).
Step:/^I set the time to "(\d\d:\d\d)" on TimePicker with index "([^\"]*)"$/
Description:Enters the supplied time into the TimePicker with the given index. The first argument is the time. The time format is (HH:mm). Second argument is the index
Step: /^I set the "([^\"]*)" time to "(\d\d:\d\d)"$/
Description:Enters the supplied date into the DatePicker with the given content description. The first argument is the content description.The second argument is the time. The time format is (HH:mm).
Setting locations
Sometimes you might want to test location aware parts of your application. You can use the following steps to persuade the phones that they are in some location of your choice.Please notice that you need to set the ACCESS_MOCK_LOCATION along with ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION to use these steps.
Step:/^I am in "([^\"]*)"$//^I am at "([^\"]*)"$/
/^I go to "([^\"]*)"$/
Description:Sets the phones gps location based on the given string. When the test is running the string is translated into a gps coordinate using Google's geocoding api
Step:/^I am at ([-+]?[0-9]*\.?[0-9]+), ([-+]?[0-9]*\.?[0-9]+)$//^I to to ([-+]?[0-9]*\.?[0-9]+), ([-+]?[0-9]*\.?[0-9]+)$/
Description: Sets the phones gps location to the given coordinate. (latitude, longitude)
Taking pictures
This is the step that allows you to take screenshots of the app in its current state.
Step: /^take picture$/
Description: Allows you to take a screenshot of the app in its current state. Remember: Your scenarios must start with the /^my app is running$/ step
Handling timing issues
You want your tests to be robust and timing issues is one of the most common root causes for flaky tests. Waiting for a specific amount of time is bad (but possible) but is bound to end in tears. Waiting for a specific condition is great. eg. wait for a button before pressing it, waiting for a specific text that indicates that the next activity has started.
Command-line accces
What is the fun of writing automatic tests if you then have to login to a web page to actually run them?Well luckily you will not have to because you can start them from the command-line.
Starting tests
First of all make sure you have set up a user secret for your project. You can find it under My Projects › [your project] › Secrets. Got it? We'll be using cURL so make sure you have that as well.
Then all you have to do is thiscurl -F "secret=[your_secret]" -F "app=@[path to your Android app]" -F "test[]=@[path to a test]" -F "test[]=@[path to another test]" http://www.lesspainful.com/cmd_upload
Lets break that down a little:
-F "secret=[your_secret]" is where you supply your user secret (without the '[' and ']' show here but with the quotes).
-F "app=@[path to your Android app]". Insert the path (on you local file system) to your .apk file -F "test[]=@[path to a test]". Insert the path (on you local file system) to a .feature test file. You can upload as many feature files as you wish
Test status
After starting a test you can access its status by issuing this command:curl -F "secret=[your_secret]" -F "id=[test_id]"
http://www.lesspainful.com/cmd_status test_id is the id returned when you started the test.If you don't provide an id you will get back the status of the last ten tests.
Running test code:
Feature: Login Scenario: Login to the app Given my app is running And I wait for "Hello!" to appear Then take picture Then I enter "jonas" as "username" And I enter "password" as "password" Then take picture Then I press "Login" And I wait for "Welcome" to appear
Then take picture
The test reportTime to take a look at the test result.
My Tests
The "My tests" page gives an overview of the tests you have run for this project and how many phone minutes (PM) were spend running this test. We'll just select the the test we have just run and have a look at the result.Notice that it takes a few minutes to run the test so all of the results might not be ready yet.
The test report
We'll be looking at the test report in small section but you can see the whole thing here
The test report has a column for each phone you are testing on. In this instance the HTC Desire, HTC Gratia, Samsung Galaxy S and Sony Ericsson X10 Mini Pro.
Each row of the table represents one step of your test. Green indicates that the step succeededRedindicates that the step failedAnd gray indicates that the step was skipped and not run. After detecting the first failure in a test the test stops running and all subsequent steps will be marked as skipped.
As you can see the table contains screenshots in those rows where we had "Then take picture" steps.It is these screenshots that are going to help you spot visual errors. So make sure and use them!
‹ Running the test | Writing a testable app ›
Making the app testableWe've been skirting around the issue so far. What exactly is required of your app to make it testable?
AndroidManifest.xml
Below is the manifest file from the test app we've been testing so far.
<?xml version="1.0" encoding="utf-8"?><manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.lesspainful.simpleui" android:versionCode="1" android:versionName="1.0"> <application android:icon="@drawable/icon" android:label="@string/app_name"> <activity android:name="com.lesspainful.simpleui.MainActivity" android:label="@string/app_name"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER"/> </intent-filter> </activity> <activity android:name="com.lesspainful.simpleui.FooActivity"/> </application>
<uses-permission android:name="android.permission.INTERNET"/> <uses-sdk android:minSdkVersion="4" /></manifest>
view raw AndroidManifest.xml This Gist brought to you by GitHub.
What is of importance here are the <uses-permission> and <uses-sdk> tags.Due to they way we run tests you application need to have the "INTERNET" permission when its being tested.We also require a minimum sdk-level of 4 (Android 1.6). You don't actually have to specify this to test but at least now you know that you you have to be at API level 4 or above.
How we resolve Views
So how exactly do we know which button to press? And which EditText to enter text into? Get the full picture in the documentation or stay here for the short(er) version. Most often we will find the correct View by looking at their android:contentDescription. So then your tests states And I enter "Erik" as "username" we will look for a view with content description "username". This means you should provide meaningful content descriptions your input widgets. Not only will this make your test more readable it will also help with accessibility (see:Designing for Accessibility).Buttons will often be resolved by their text. Content descriptions can be given in two ways depending on whether your UI is xml based or not.
<EditText android:id="@+id/username_edittext" android:layout_width="fill_parent" android:layout_height="wrap_content" android:contentDescription="username"/>view raw content_description_in.xml This Gist brought to you by GitHub.
For xml based layouts use the android:contentDescription attribute as above.And for programmatic layouts use setContentDescription as below.
EditText usernameEditText = new EditText(this);usernameEditText.setContentDescription("username");view raw content_description_in.java This Gist brought to you by GitHub.
Without Content Descriptions
If for some reason you don't want to use contentDescriptions you don't have to. We do supply tests steps that do not rely on these. But you should in mind that using these will reduce the readability of you tests and possibly the robustness. You can find the full details in the documentation but below is given an example of a test using these steps.
Feature: Login
Scenario: Login to the App, without using content descriptions.
Given my app is runningAnd I wait for "Hello!" to appearThen take pictureThen I enter "Erik" into input field number 0And I enter "password" into input field number 1Then I press "login"view raw no_contentDescription_test.feature This Gist brought to you by GitHub.
The endEnd of the road. You've finished the tutorial. For more information take a look at the documentation.And if you have any questions or run into trouble please let us know:[email protected] / twitter
available devices
Amazon - Kindle Fire (2.3 Kindle Fire)
HTC - Legend (2.2) Samsung - Galaxy Nexus (4.0.1)
Apple - iPhone4 (4.3.3) HTC - Wildfire (2.2.1) Samsung - Galaxy S (2.1-update1)
Apple - iPhone4S (5.0) HTC - Wildfire S (2.3.3) Samsung - Galaxy S II (2.3.3)
Garmin Asus - A50 nuvifone (2.1-update1)
LG - GT540 (2.1-update1) Samsung - Galaxy mini (2.2.1)
HTC - ChaCha (2.3.3) LG - Optimus 2X (2.2.2) Sony Ericsson - Xperia Arc (2.3.3)
HTC - Desire (2.2) LG - P350 (2.2.2)Sony Ericsson - Xperia X10 (2.1-update1)
HTC - Desire HD (2.2.1) LG - P500 (2.2)Sony Ericsson - Xperia X10 mini (2.1-update1)
HTC - Incredible S (2.2.1) Motorola - MOTODEFY (2.2.2)Sony Ericsson - Xperia X8 (2.1-update1)
HTC - Legend (2.1)Motorola - PHOTON 4G MB855 (2.3.4)
