Search code examples
iosautomationui-automationios-ui-automation

iPhone app UI automation test design

Hi Automation/iOS Experts,

We have launched a new iPhone app project recently and would like to automate some basic acceptance tests using Apple's UIAutomation Instruments. Now we have a very basic framework for this task. This framework simply encapsulates the underlying JS functions provided by Apple in Java(to provide some debugging abilities) and drives the tests by Junit. The tests run in iPhone Simulator.

So the background is Instruments + Eclipse + Java + Junit + iPhone Simulator.

In writing the tests, I found the tests are greatly affected by the app's "states". For example, The app shows some kind of "Terms of use" page when first run, but never again until the iPhone simulator is reset. After the user accepts the "Terms of use", she will be taken to a "Home" page, where she can input some search criteria and hit "search" and taken to search result page. Then she can be taken to a "View detail" page.

TOU -> Home -> Search Result -> View Detail.

Please keep in mind this is only a very simplified version of my real app.

Now here is the question: In order to automatically test the view detail function, shall my test go through all the previous steps(assuming that the app is always started afresh without any states saved)? or should my tests assume some pre-conditions(like "View Detail" tests assuming that my app is at "Search Result")?

Please give your reasons. And sorry if my English is hard to understand as it's not my mother tongue.

Thanks!

Vince

Solution

  • "Pre-conditions" / "known baseline" / "known state" are golden for automation. Even more so for UI testing since they have more variations that can cause test failures for issues unrelated to what your test was doing.

    So from an automation perspective - go directly to the 'View Detail' test. The majority of your automated test scripts will be in those types of functional areas. TOU, etc. are one-time per reset/install. So two options:

    1. First run an automated script to clear the TOU and exit, followed by all other tests that deal with home page, searching, etc. Or...
    2. Clear the TOU manually, followed by all other tests.
    3. Bonus option: you could also test that the TOU doesn't appear more than once per reset, since it shouldn't. That could be first and second test you always run each time. Then run the remaining tests.

    If your automated always rely on the TOU appearing, then after the first test, the others will fail since the TOU won't appear until the next reset/test cycle. You could put a 'handler' at the start of all your automated tests to conditionally manage the TOU page. In this situation, I would go with option #1 above.