Confirmed users
975
edits
Auto-tools/Projects/Robocop/WritingTests: Difference between revisions
Auto-tools/Projects/Robocop/WritingTests (view source)
Revision as of 01:01, 4 December 2013
, 4 December 2013Correct headers
(Update links w/ descriptions) |
m (Correct headers) |
||
| Line 1: | Line 1: | ||
= What's this? = | == What's this? == | ||
Robotium is a test framework created to make it easy to write powerful and robust automatic black-box test cases for Android applications. Robocop provides a wrapper around Robotium making it even easier to write and execute UI tests for native Fennec. | Robotium is a test framework created to make it easy to write powerful and robust automatic black-box test cases for Android applications. Robocop provides a wrapper around Robotium making it even easier to write and execute UI tests for native Fennec. | ||
= Creating a new test = | == Creating a new test == | ||
The best way to create a new Robocop test is to copy and modify an existing one -- see mobile/android/base/tests. | The best way to create a new Robocop test is to copy and modify an existing one -- see mobile/android/base/tests. | ||
| Line 46: | Line 46: | ||
</pre> | </pre> | ||
== Creating a new Content Provider test == | === Creating a new Content Provider test === | ||
We have infrastructure for testing content providers in an isolated environment. This means that we ensure that any updates to the databases behind content providers will not affect or be affected by Firefox. | We have infrastructure for testing content providers in an isolated environment. This means that we ensure that any updates to the databases behind content providers will not affect or be affected by Firefox. | ||
| Line 67: | Line 67: | ||
After this is called, ''mProvider'' will point to an isolated instance of your content provider and you can make insert/query/update/delete calls on it as expected. For more details and sample code on how to implement Content Provider tests, see testBrowserProvider.java.in. | After this is called, ''mProvider'' will point to an isolated instance of your content provider and you can make insert/query/update/delete calls on it as expected. For more details and sample code on how to implement Content Provider tests, see testBrowserProvider.java.in. | ||
= APIs = | == APIs == | ||
Robotium itself provides a rich API through the Solo class - [http://robotium.googlecode.com/svn/doc/index.html javadocs] [1] for Solo are available. | Robotium itself provides a rich API through the Solo class - [http://robotium.googlecode.com/svn/doc/index.html javadocs] [1] for Solo are available. | ||
| Line 120: | Line 120: | ||
Finally, an evolving set of test base classes - BaseTest, PixelTest, etc - can be leveraged for some types of tests. | Finally, an evolving set of test base classes - BaseTest, PixelTest, etc - can be leveraged for some types of tests. | ||
= Tips = | == Tips == | ||
=== Event timing === | === Event timing === | ||
A recurring issue when writing UI tests is the timing of events. To enter a URL, you need to click on the awesome bar and then send the key events for the text. If you click() and then immediately sendKeys(), the text probably won't get to the awesome bar. If you sleep() briefly before and after clicking, the task will probably succeed...but how long are those sleep() calls? Will the test still work on other devices, reliably? Avoid the temptation to scatter sleep() throughout your test. Whenever possible, wait for events or other feedback to verify the UI is in the required state before proceeding. For example, many tests will want to wait for startup before starting the test: driver.waitForGeckoEvent("Gecko:Ready"). | A recurring issue when writing UI tests is the timing of events. To enter a URL, you need to click on the awesome bar and then send the key events for the text. If you click() and then immediately sendKeys(), the text probably won't get to the awesome bar. If you sleep() briefly before and after clicking, the task will probably succeed...but how long are those sleep() calls? Will the test still work on other devices, reliably? Avoid the temptation to scatter sleep() throughout your test. Whenever possible, wait for events or other feedback to verify the UI is in the required state before proceeding. For example, many tests will want to wait for startup before starting the test: driver.waitForGeckoEvent("Gecko:Ready"). | ||
| Line 177: | Line 177: | ||
Note that the test is therefore dependent on screen size and orientation, as well as Robotium scrolling behavior. | Note that the test is therefore dependent on screen size and orientation, as well as Robotium scrolling behavior. | ||
= Useful links = | == Useful links == | ||
[1] Robotium 4.2 javadocs: http://robotium.googlecode.com/svn/doc/index.html | [1] Robotium 4.2 javadocs: http://robotium.googlecode.com/svn/doc/index.html | ||