118
edits
Auto-tools/Projects/Robocop/WritingTests: Difference between revisions
Auto-tools/Projects/Robocop/WritingTests (view source)
Revision as of 14:20, 9 March 2016
, 9 March 2016→Logging
(Update links w/ descriptions) |
|||
| (4 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
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. | |||
New tests should probably use the UITest base class - see the documentation at [[Mobile/Fennec/Android/UITest|UITest]]. Most of the information below will also be relevant to users of UITest (though the information should probably be curated). | |||
= Creating a new test = | == Creating a new test == | ||
These tests will extend BaseTest. | |||
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 47: | ||
</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 68: | ||
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 121: | ||
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 128: | Line 129: | ||
=== Logging === | === Logging === | ||
Robocop logs to both logcat and a file log via Assert.dumpLog (or FennecNativeDriver.log). Test code can use these, or log as a side-effect of Assert.is, Assert.ok, etc. Do not call android.util.Log.i/w/e/etc directly. | Robocop logs to both logcat and a file log via Assert.dumpLog (or FennecNativeDriver.log). Test code can use these, or log as a side-effect of Assert.is, Assert.ok, etc. Do not call android.util.Log.i/w/e/etc directly. | ||
'''Robocat''' is a command line tool to transform the JSON robocop dumps into logcat into a human-readable format: https://github.com/pocmo/Robocat | |||
=== Indirect Database Operations === | === Indirect Database Operations === | ||
| Line 177: | Line 180: | ||
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 == | ||
#[[Mobile/Fennec/Android/UITest|Our UITest base class documentation]] | |||
[ | #Latest Robotium javadocs: http://robotium.googlecode.com/svn/doc/index.html | ||
#Robotium project page: http://code.google.com/p/robotium/ | |||
#Robotium changelog for versions: http://code.google.com/p/robotium/wiki/Changelog | |||
#Robotium GitHub repo: https://github.com/jayway/robotium/tree/master/robotium-solo/src/main/java/com/jayway/android/robotium/solo | |||