Follow-up to #274 (lane 5). #274's AccountPickerScreenTest covers the picker's vendor choices, but not that the Outlook choice actually launches the browser for Microsoft OAuth. Repo owner wants this specific in-app behavior tested.
Scope (deliberately narrow)
Verify only that tapping the Outlook button launches the browser correctly — i.e. the AppAuth authorization intent (browser / Custom Tab to the Microsoft OAuth authorize endpoint) is fired on tap. Do NOT test the OAuth redirect handling, token exchange, or account creation.
:125-133 Outlook button → viewModel.outlookAuthIntent().fold(...) → outlookLauncher.launch(intent) (:130), with runCatching { ... }.onFailure { viewModel.onOutlookLaunchFailed(it) }.
The intent is the AppAuth authorization intent built by OutlookAuthManager (net.openid.appauth.AuthorizationService).
Suggested approach
Instrumented test using Espresso-Intents (Intents.init() + intending(...) to stub the result so no real browser opens + intended(...) to assert). Drive AccountPickerScreen with a ViewModel whose outlookAuthIntent() returns a known browser-launch intent (or the real one), tap the Outlook button, and assert the launched intent targets the browser / AppAuth authorization (e.g. matches AppAuth's AuthorizationManagementActivity, or an ACTION_VIEW/Custom-Tab intent to the Microsoft login.microsoftonline.com authorize host). Optionally also assert the runCatching failure path routes to onOutlookLaunchFailed when the launch throws.
Dependency / DoD
Extend #274's AccountPickerScreenTest (or add a sibling test) — do this after #274 merges so the base test exists.
DoD: instrumented test runs and passes in CI, asserting the browser-launch intent fires on Outlook tap.
Follow-up to **#274** (lane 5). #274's `AccountPickerScreenTest` covers the picker's vendor choices, but not that the **Outlook** choice actually launches the browser for Microsoft OAuth. Repo owner wants this specific in-app behavior tested.
## Scope (deliberately narrow)
Verify **only** that tapping the Outlook button launches the browser correctly — i.e. the AppAuth authorization intent (browser / Custom Tab to the Microsoft OAuth authorize endpoint) is fired on tap. **Do NOT** test the OAuth redirect handling, token exchange, or account creation.
## Mechanism (where to hook)
`app/src/main/kotlin/org/libremail/ui/accountsetup/AccountPickerScreen.kt`:
- `:73` `outlookLauncher = rememberLauncherForActivityResult(StartActivityForResult)`
- `:125-133` Outlook button → `viewModel.outlookAuthIntent().fold(...)` → `outlookLauncher.launch(intent)` (`:130`), with `runCatching { ... }.onFailure { viewModel.onOutlookLaunchFailed(it) }`.
- The intent is the AppAuth authorization intent built by `OutlookAuthManager` (`net.openid.appauth.AuthorizationService`).
## Suggested approach
Instrumented test using **Espresso-Intents** (`Intents.init()` + `intending(...)` to stub the result so no real browser opens + `intended(...)` to assert). Drive `AccountPickerScreen` with a ViewModel whose `outlookAuthIntent()` returns a known browser-launch intent (or the real one), tap the Outlook button, and assert the launched intent targets the browser / AppAuth authorization (e.g. matches AppAuth's `AuthorizationManagementActivity`, or an `ACTION_VIEW`/Custom-Tab intent to the Microsoft `login.microsoftonline.com` authorize host). Optionally also assert the `runCatching` failure path routes to `onOutlookLaunchFailed` when the launch throws.
## Dependency / DoD
- Extend #274's `AccountPickerScreenTest` (or add a sibling test) — do this **after #274 merges** so the base test exists.
- DoD: instrumented test runs and passes in CI, asserting the browser-launch intent fires on Outlook tap.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Follow-up to #274 (lane 5). #274's
AccountPickerScreenTestcovers the picker's vendor choices, but not that the Outlook choice actually launches the browser for Microsoft OAuth. Repo owner wants this specific in-app behavior tested.Scope (deliberately narrow)
Verify only that tapping the Outlook button launches the browser correctly — i.e. the AppAuth authorization intent (browser / Custom Tab to the Microsoft OAuth authorize endpoint) is fired on tap. Do NOT test the OAuth redirect handling, token exchange, or account creation.
Mechanism (where to hook)
app/src/main/kotlin/org/libremail/ui/accountsetup/AccountPickerScreen.kt::73outlookLauncher = rememberLauncherForActivityResult(StartActivityForResult):125-133Outlook button →viewModel.outlookAuthIntent().fold(...)→outlookLauncher.launch(intent)(:130), withrunCatching { ... }.onFailure { viewModel.onOutlookLaunchFailed(it) }.OutlookAuthManager(net.openid.appauth.AuthorizationService).Suggested approach
Instrumented test using Espresso-Intents (
Intents.init()+intending(...)to stub the result so no real browser opens +intended(...)to assert). DriveAccountPickerScreenwith a ViewModel whoseoutlookAuthIntent()returns a known browser-launch intent (or the real one), tap the Outlook button, and assert the launched intent targets the browser / AppAuth authorization (e.g. matches AppAuth'sAuthorizationManagementActivity, or anACTION_VIEW/Custom-Tab intent to the Microsoftlogin.microsoftonline.comauthorize host). Optionally also assert therunCatchingfailure path routes toonOutlookLaunchFailedwhen the launch throws.Dependency / DoD
AccountPickerScreenTest(or add a sibling test) — do this after #274 merges so the base test exists.