test(examples): add end-to-end tests for the authentication example#1628
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe authentication example adds a Flutter integration test suite covering password, email and phone OTP, anonymous upgrade, MFA, and OAuth UI flows against local Supabase services. Documentation and runtime packages explain and support test execution. ChangesAuthentication integration coverage
Estimated code review effort: 4 (Complex) | ~45 minutes Suggested reviewers: Sequence Diagram(s)sequenceDiagram
participant TestSuite
participant AuthenticationExample
participant LocalSupabase
participant LocalMailServer
TestSuite->>AuthenticationExample: drive authentication UI
AuthenticationExample->>LocalSupabase: submit sign-up, sign-in, reset, or OTP request
LocalSupabase->>LocalMailServer: deliver recovery or email OTP
TestSuite->>LocalMailServer: retrieve six-digit code
TestSuite->>AuthenticationExample: enter code or TOTP
AuthenticationExample->>LocalSupabase: verify credentials or factor
LocalSupabase-->>AuthenticationExample: update authenticated session
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Add a single example under examples/authentication that demonstrates every supabase_flutter sign in method except passkeys: email & password, magic link and email OTP, phone (SMS) OTP, OAuth social, anonymous sign in with account upgrade, and TOTP multi-factor authentication. All auth calls live in a thin AuthRepository so the flows are easy to read and to drive from an integration test. The shared Supabase config enables anonymous sign in, phone auth with a local test OTP, TOTP MFA and the local mail server. Covers SDK-1059, SDK-1060, SDK-1061, SDK-1062, SDK-1063 and SDK-1064.
The default magic-link email only carries a link, so the authentication
example's email OTP flow could not be completed by typing a code. Add a custom
magic_link template that also shows {{ .Token }}, matching what the example's UI
and README describe.
…n example The example only sent the reset email. Add the recovery step: enter the code from the email and a new password to finish the reset (verifyOTP with OtpType.recovery, then updateUser). Add a recovery email template that includes the code, matching the magic-link one.
Two fixes in the authentication example found while writing its tests: - A phone-only user comes back with an empty email string, so the account title fell back to nothing instead of the phone number. - The signed-in view was a const instance, which the framework skips rebuilding, so upgrading an anonymous account did not refresh the screen. Pass the user in so it rebuilds on every auth change.
Pass a redirectTo/emailRedirectTo through the OAuth, magic link/email OTP and password reset calls so native builds return to the app after the provider or email link, using a deep link that is null on web (site URL) and registered in the shared config's additional_redirect_urls.
bf794de to
e6a6196
Compare
Drive the authentication app widgets against the local stack, one sign in method per test: email & password, a full password reset, passwordless email OTP, phone SMS OTP, anonymous sign in with account upgrade, and enrolling then removing a TOTP MFA factor. Also assert the OAuth provider buttons render. The password reset and email OTP tests read the code back from the local mail server, which a browser blocks cross-origin, so they are skipped on web and run on native targets such as -d macos. OAuth's redirect hands off to an external browser and is left to manual testing.
de1a599 to
d642da6
Compare
…ds (#1627) ## What Adds a single example app under `examples/authentication` that demonstrates every `supabase_flutter` sign in method except passkeys (which already have their own [`passkeys`](../passkeys) example). Pick a method with the chips at the top; once signed in you land on an account screen that manages MFA and can upgrade an anonymous user to a permanent account. Covers these parity example tickets: - **SDK-1059** Email & password: `signUp`, `signInWithPassword`, and a full password reset (`resetPasswordForEmail`, then `verifyOTP` with `OtpType.recovery` and `updateUser`) - **SDK-1060** Passwordless: `signInWithOtp(email:)` + `verifyOTP(type: OtpType.email)` - **SDK-1061** OAuth social: `signInWithOAuth` (Google, GitHub, Apple), including deep-link redirect - **SDK-1062** Phone / SMS: `signInWithOtp(phone:)` + `verifyOTP(type: OtpType.sms)` - **SDK-1063** Anonymous: `signInAnonymously`, then `updateUser` to upgrade to a permanent account - **SDK-1064** MFA (TOTP): `auth.mfa.enroll`, `challengeAndVerify`, `listFactors`, `unenroll` ## How - All `supabase.auth.*` calls live in `lib/auth_repository.dart`, kept separate from the UI so the flows are easy to read and to drive from an integration test. The UI just calls the repository and rebuilds from `onAuthStateChange`. - Follows the structure, naming and comment style of the `database_crud` example. - The shared Supabase config in `examples/supabase/config.toml` enables anonymous sign in, phone auth (with a local test OTP so no SMS provider is needed), TOTP MFA, and the local mail server. Custom `magic_link` and `recovery` email templates include the one-time code so the email OTP and reset flows can be completed by typing it. `[inbucket]` was renamed to the current `[local_smtp]` section along the way. The example stores no data of its own, so it needs no migration or seed. ## Testing Booted the shared local stack and verified against the API that email/password sign up, email OTP (captured by the local mail server), the full password reset loop, phone OTP with the test number, anonymous sign in and its upgrade to a permanent account all work. `dart format` and `flutter analyze` are clean. End-to-end integration tests follow in stacked PR #1628; writing them surfaced two display/rebuild bugs that are fixed here. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added a Flutter authentication example covering password, magic-link/email OTP, phone OTP, OAuth, anonymous sign-in, password recovery, and TOTP MFA. - Added native deep-link handling for email and OAuth flows. - Added local authentication testing support, including email capture and fixed SMS OTP configuration. - Added magic-link and password-recovery email templates displaying verification codes and links. - **Documentation** - Added setup, configuration, usage, and local testing instructions for the authentication example. - Updated the examples feature table. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
…9-1064-example-authentication-tests # Conflicts: # examples/README.md # examples/authentication/README.md # examples/authentication/pubspec.yaml
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@examples/authentication/README.md`:
- Around line 97-103: Update the integration-test networking instructions in the
README to distinguish macOS host loopback from Android emulator and
physical-device access. Document the Android emulator alias or adb reverse setup
for both Supabase port 54321 and Mailpit port 54324, or explicitly restrict the
existing localhost command to macOS.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: f0c313f8-0801-4e5c-b665-43f61840fcc9
📒 Files selected for processing (3)
examples/authentication/README.mdexamples/authentication/integration_test/authentication_test.dartexamples/authentication/pubspec.yaml
Stacked on #1627.
What
Adds
examples/authentication/integration_test/authentication_test.dart, an end-to-end suite that drives the authentication app widgets against the local Supabase stack, mirroring thedatabase_crudandpasskeysexample tests. One sign in method per test:Adds
cryptoandhttpas dev dependencies, used only by the test to compute the TOTP code and to read OTP emails from the local mail server.Web vs native targets
The password reset and email OTP tests read the code back from the local mail server over HTTP. A browser blocks that cross-origin request, so those two are skipped on web (via
kIsWeb) and run on native targets such as-d macos, where there is no such restriction.Verification
Ran the suite headlessly against the running local stack (Chrome + chromedriver): 7 passed, 2 skipped, 0 failed. The five widget-driven flows that don't touch the mail server pass end to end (email & password, phone SMS OTP, anonymous + upgrade, MFA, OAuth buttons), and the two mail-server tests are skipped on web. Both skipped flows were additionally validated end to end against the backend API (email delivery, the six-digit-code extraction, recovery verify, and setting a new password), and they run on
-d macos.Writing the tests surfaced two real bugs in the example, fixed in the base PR #1627: a phone-only user has an empty email string (so the account title showed nothing), and the signed-in view was a
constinstance the framework skipped rebuilding (so an anonymous upgrade did not refresh the screen).dart formatandflutter analyzeare clean.Summary by CodeRabbit
flutter testcommand.