I have generated about 60 Android UI tests using UiAutomator, but I'm wondering if there may be a better way to implement them. Most of the answers I find (below) are simple one-test examples that don't translate to large-scale testing suites.
Examples:
The way I have been organizing my tests up to this point has been to each piece individually, depending on the screen they are on (Home, vs. a List, vs. a Report). Then, I create functions depending on that screen, and finally generate tests / workflows based on those functions. For example:
A public object:
public class ExampleObjects {
public static UiObject BODY = new UiObject(new UiSelector.resourceId("android:id/body"));
}
A public function (which applies to a test):
public class ExampleFunctions {
public static boolean isReportDeleted(String reportID) {
// do stuff
ExampleObjects.BODY.click();
// do more stuff
}
}
And finally the tests themselves:
public class ExampleTest extends UiAutomatorTestCase {
public String REPORT_ID = "101";
public void setUp() {
// set up stuff
}
public void tearDown() {
// tear down stuff
}
public void test_exampleTest() {
assertTrue(ExampleFunctions.isReportDeleted(REPORT_ID);
}
}
The tests themselves are JUnit style - one assertion that applies to a function defined in a different class. This makes it so I only need to fix one function if the UI changes, but I still have my tests.
My Questions:
- Given the examples that I've seen, it looks like a lot of testers prefer to create new UiObjects / UiSelectors within the tests, as they write them. Is this common, and a better approach than what I have right now?
- I haven't had any luck with using the UiWatchers, and I was wondering if my separation of objects / functions / tests means that the UiWatchers are ineffective. Should the watchers be defined within the tests themselves?
Thank you very much for your input.
Aucun commentaire:
Enregistrer un commentaire