How would you set Appium's reset capabilities for a ferry timetable suite running on both Android and iOS?
answer
- one value, two different guarantees
- cost per session versus contamination risk
- isolation in capabilities or in the suite
- assert the starting state, never assume it
basics
~20 sChoose per platform, not once: Android can clear data in place cheaply, so the default reset is affordable there, while an iOS lane either pays for a reinstall every session or makes the suite reset the state itself.
solid answer
~50 sI would stop treating `appium:noReset` and `appium:fullReset` as one shared setting, because the same value buys different guarantees on each platform. On Android the default reset is a cheap in-place data clear, so leaving both flags false is usually right, with `appium:forceAppLaunch` when the suite also needs a predictable first screen. On iOS that same default only means *reinstall if there is a build to install*, so I either ship the artifact with every session and accept the install cost, or I set `appium:noReset` true on both lanes and make clean state an explicit step the suite owns — sign out, reset through a back door, seed the account. What I will not do is let the flags imply an isolation the Apple lane never delivered. Whichever way it goes, the case asserts the state it expects first, so a dirty start fails loudly.
go deeper
Take away the shape of the decision: faster sessions mean more state carried over, and cleaner sessions cost time. You are not expected to price that trade-off yet.
Be able to say what each of the three strategies does on each platform, and why the cheapest clean option on Android has no equally cheap counterpart on Apple hardware.
Argue the choice with numbers — session start-up cost against contamination risk — and insist on an assertion that makes a dirty start fail at the first step instead of flaking later.
Own the contract across the fleet: decide whether isolation is a driver capability or suite-owned code, write down which, and make it observable so nobody has to trust a value nobody has verified.
## The decision is per platform, not per suite The instinct is to put one reset policy in one shared capability block and let both lanes inherit it. That is the wrong shape here, because `appium:noReset` and `appium:fullReset` express **intent** while each driver supplies a **mechanism**, and the mechanisms are not equivalent. On Android the drivers clear the app's data in place through the package manager: cheap, unconditional, and identical on an emulator and a phone. On Apple platforms the XCUITest driver has no in-place clear for a device, so its clean-up is a reinstall, which only happens when the session has a build to install — and the one in-place lever, `mobile: clearApp`, is simulator-only. So the same `appium:noReset: false` is a strong guarantee on one lane and a conditional one on the other. A shared block does not make the lanes consistent; it hides that they are not. ## Three strategies and what each really costs | strategy | Android | Apple platforms | verdict | |---|---|---|---| | both flags false, no artifact shipped | genuinely clean each session, near-free | may be a complete no-op | the trap: looks uniform, is not | | both flags false, artifact shipped every session | clean each session, near-free | clean each session, install cost per run | honest, and the iOS lane pays for it | | `appium:fullReset` true | removal plus install every session | removal plus install every session | strongest, slowest, keep it narrow | | `appium:noReset` true plus a suite-owned reset | identical on both lanes | identical on both lanes | fastest start-up, most code to own | The row worth dwelling on is the first, because it is what most suites drift into. Nothing fails, the Android numbers look good, and the Apple lane has quietly been reusing state for months. ## Where I would put the isolation My default for this ferry timetable suite: - **Android lane** — leave both reset flags false. The data clear costs almost nothing and the guarantee is unconditional, so there is no reason to buy anything more expensive. - **Apple lane** — decide explicitly between shipping the build every session and owning the reset in the suite, and write the decision down next to the capabilities so the next reader does not have to infer it. - **The few first-run cases** — an empty timetable, the onboarding screen, a migration from no saved home port — get `appium:fullReset` on both lanes. They are the cases that genuinely need a removal, and there should be a handful of them, not a suite of them. - **Everything else** — asserts its starting state in its first step, whichever strategy produced it. That last bullet is the one I would fight for in review. A reset strategy you have not observed working is a belief, not a control, and the cheapest place to convert it is an assertion at the top of the case that fails loudly on a dirty start. ## The Android-only knobs, and why they prove the point Android has two capabilities around this that have no Apple twin at all: `appium:forceAppLaunch`, which starts the app under test again at session start even when `appium:noReset` is true, and `appium:dontStopAppOnReset`, which leaves the app running rather than stopping it first. They let an Android lane keep the speed of a no-reset session and still get a predictable first screen. That asymmetry is the argument against a single shared block, made concrete: the fast Android configuration has knobs the fast Apple configuration cannot express. Any config layer that pretends the two lanes take the same keys will end up carrying Android-only names that the Apple lane silently ignores. ## How I would prove the choice is working 1. **Write a marker in one session and read it in the next**, per platform, as a standing check rather than a one-off investigation. 2. **Confirm from the server log** that the Apple lane actually installs something at session start, if the strategy depends on the reinstall. 3. **Assert the pre-state in the case**, so contamination surfaces as a clear first-step failure instead of a flake three screens in. 4. **Re-measure the cost** after the choice ships: session start-up is a fixed tax on every case, and a full reset on a real-device lane is the most expensive line in that budget. ## What I would refuse to do I would refuse to set `appium:fullReset` across a whole suite to feel safe, because on Android it buys something a data clear already gives for a fraction of the time. I would equally refuse to run `appium:noReset` true everywhere without a reset path in the suite, because that is not a speed decision, it is an isolation decision made silently. And I would refuse to describe either lane as isolated on the strength of the capability value alone.
- When is appium:fullReset the right default for a whole lane rather than a few cases?When the lane exists to test first run — onboarding, empty states, migration from no stored data — where anything left behind changes the behaviour under test. Everywhere else the per-session removal and install is a large fixed tax for a guarantee that a cheap in-place clear already gives you on Android.
- If the suite owns clean state instead of the capabilities, what has to be true for that to hold?The reset path has to exist in every build you test, run quickly, and be verifiable: a sign-out or a back door the app exposes, plus an assertion at the start of the case that the state really is what you asked for. Otherwise you have swapped a silent driver assumption for a silent suite one.
saying these in an interview costs you the question
- Ships one shared reset capability block for both platforms
- Sets a full reset everywhere and absorbs the run time
- Calls a lane isolated without asserting the starting state
- Assumes a no-reset session costs only mild contamination
- Expects the Android-only knobs to have Apple equivalents