settings: Migrate to new RadioGroup API; write widget tests for two just-added settings #1602

chrisbobbe · 2025-06-17T21:23:37Z

Fixes part of:

gnprice

Thanks for taking care of this (including writing those tests)! All looks good; some nits and for-the-future musings below.

This also seems like definitely a good change in the upstream API, too — better structured to match how the UI really works (or at least should work, for radio buttons to be the right fit).

gnprice · 2025-06-18T02:03:40Z

test/widgets/settings_test.dart

+      for (final setting in VisitFirstUnreadSetting.values) {
+        final thisSettingTitle = settingTitle(setting);
+        checkRadioButtonAppearsChecked<VisitFirstUnreadSetting>(tester,
+          thisSettingTitle, thisSettingTitle == settingTitle(expectedSetting));


This comparison can be on the values directly instead of the labels, right?

Suggested change

for (final setting in VisitFirstUnreadSetting.values) {

final thisSettingTitle = settingTitle(setting);

checkRadioButtonAppearsChecked<VisitFirstUnreadSetting>(tester,

thisSettingTitle, thisSettingTitle == settingTitle(expectedSetting));

for (final setting in VisitFirstUnreadSetting.values) {

final thisSettingTitle = settingTitle(setting);

checkRadioButtonAppearsChecked<VisitFirstUnreadSetting>(tester,

thisSettingTitle, setting == expectedSetting);

gnprice · 2025-06-18T02:05:17Z

test/widgets/settings_test.dart

+    testNavObserver = TestNavigatorObserver()
+      ..onPushed = ((route, _) => lastPushedRoute = route)
+      ..onPopped = ((route, _) => lastPoppedRoute = route);
+    lastPushedRoute = null;
+    lastPoppedRoute = null;


Not for this PR, but: given how much this pattern is recurring now, I'm thinking it'd be good to centralize the code for it.

Perhaps by giving TestNavigatorObserver (or a subclass) some more structure, to track this sort of state itself.

Indeed; #1668

gnprice · 2025-06-18T02:11:28Z

test/widgets/settings_test.dart

+      await tester.pump();
+      check(lastPushedRoute).isA<MaterialWidgetRoute>()
+        .page.isA<VisitFirstUnreadSettingPage>();
+      await tester.pump((lastPushedRoute as TransitionRoute).transitionDuration);


(again not for this PR)

If the nav observer tracks a log of both pushes and pops in a single list (or I guess even just tracks the last single such action), then this could perhaps even look something like:

Suggested change

await tester.pump((lastPushedRoute as TransitionRoute).transitionDuration);

await tester.pump(navObserver.lastTransitionDuration);

and exactly the same in the pop case (when the last thing that happened was a pop, the lastTransitionDuration getter would look at its reverseTransitionDuration).

gnprice · 2025-06-18T02:16:19Z

test/widgets/settings_test.dart

+
+      await tester.tap(findRadioListTileWithTitle<VisitFirstUnreadSetting>(
+        settingTitle(VisitFirstUnreadSetting.always)));
+      await tester.pumpAndSettle(); // TODO why doesn't just `pump` work?


Hmm, dunno. Does pump(Duration.zero) work?

Looking at the implementation of setThemeSetting, it'll wait for the (simulated) DB write to complete before it updates the within-Dart store. In real life that's some IO that will take a small but nonzero amount of time, so its completion callback won't happen in a microtask, which is what pump() does. So it fits that that also wouldn't suffice in the test.

Ah a regular tester.pump does indeed work when I change to a semantics-based approach instead of checking what paints :)

gnprice · 2025-06-18T02:17:11Z

test/widgets/settings_test.dart

+      await tester.pumpAndSettle();
+      checkPage(tester, expectedSetting: VisitFirstUnreadSetting.never);
+
+      await tester.tap(find.byType(BackButton));


Fun alternative (see its docs) which I happened across recently while browsing other code:

Suggested change

await tester.tap(find.byType(BackButton));

await tester.tap(find.backButton());

gnprice · 2025-06-18T02:19:59Z

test/widgets/settings_test.dart

+    });
+  });
+
+  group('MarkReadOnScrollSetting', () {


If we add one or two more of these, we'll likely want to try abstracting them out a bit more — the body of the test case is repetitive enough that it risks getting hard to read without glossing over.

But explicit is always a good way to write the first version, and I think it works fine for two of these.

chrisbobbe · 2025-07-01T21:12:29Z

Hmm, flutter/flutter@a5a3ab3 breaks the "check what paints" commit. I think probably the fix is to follow a Figma design for radio buttons, instead of using Material widgets. Such a frame exists:

https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=5003-65595&t=yxYjWrPU6rpZqcUg-0

gnprice · 2025-07-02T06:13:12Z

Hmm. That's probably a good change to do eventually anyway — but it shouldn't be a blocker for this API migration. The Material widgets should have a reasonable way to test a UI that uses them.

I think one good answer would be to switch from inspecting the paint behavior to inspecting the semantics, as in SemanticsNode. That's what people using a screen-reader would encounter, and conveniently it's also by nature more structured. To explore a bit, I tried this edit to the tests:

   void checkRadioButtonAppearsChecked<T>(WidgetTester tester, String title, bool expectedIsChecked) {
     final element = tester.element(findRadioListTileWithTitle<T>(title));
+    print(element.renderObject!.debugSemantics!.toStringDeep());

and then ran the tests. The first couple of trees printed looked like this:

SemanticsNode#5
 │ merge boundary ⛔️
 │ Rect.fromLTRB(0.0, 56.0, 800.0, 112.0)
 │ actions: focus, tap
 │ flags: hasEnabledState, isEnabled, isFocusable, hasSelectedState
 │ label: "System"
 │ textDirection: ltr
 │
 └─SemanticsNode#6
     merged up ⬆️
     Rect.fromLTRB(16.0, 8.0, 56.0, 48.0)
     actions: focus, tap
     flags: hasCheckedState, hasEnabledState, isEnabled,
       isInMutuallyExclusiveGroup, isFocusable

SemanticsNode#7
 │ merge boundary ⛔️
 │ Rect.fromLTRB(0.0, 112.0, 800.0, 168.0)
 │ actions: focus, tap
 │ flags: hasEnabledState, isEnabled, isFocusable, hasSelectedState
 │ label: "Light"
 │ textDirection: ltr
 │
 └─SemanticsNode#8
     merged up ⬆️
     Rect.fromLTRB(16.0, 8.0, 56.0, 48.0)
     actions: focus, tap
     flags: hasCheckedState, isChecked, hasEnabledState, isEnabled,
       isInMutuallyExclusiveGroup, isFocusable

so it looks like that isChecked flag is the thing to inspect.

chrisbobbe · 2025-07-02T18:10:37Z

Interesting; thanks for the debugSemantics tip—I definitely tried having the test check semantics before trying the check-what-paints approach, and I couldn't get it to work (the isChecked flag wasn't present on the node where I thought it should've been)—but I may have better luck with the help of debugSemantics when I come back to this

gnprice · 2025-07-03T18:56:10Z

(Pushed here a branch intended for #1662, oops; then restored the branch that had been here.)

chrisbobbe · 2025-07-07T18:59:18Z

OK, updated, checking semantics this time. PTAL! 🙂

gnprice

Thanks! This approach looks good. One comment below.

gnprice · 2025-07-07T21:15:34Z

test/widgets/settings_test.dart

+        hasSelectedState: true,
+        hasTapAction: true,
+        hasFocusAction: true));


Hmm, annoying we have to specify all these flags that seem like not the point of these tests. But I see that's how matchesSemantics behaves.

… Oho: how about containsSemantics? Then I think this whole check statement becomes:

check(tester.semantics.find(findRadioListTileWithTitle<T>(title))) .containsSemantics( label: subtitle == null ? title : '$title\n$subtitle', isInMutuallyExclusiveGroup: true, hasCheckedState: true, isChecked: expectedIsChecked);

This tests the observable behavior more directly. RadioListTile.checked has been deprecated (zulip#1545), so we'd like this test to stop relying on that implementation detail.

"Open message feeds at" and "Mark messages as read on scroll". Related: zulip#1571 Related: zulip#1583

This migration is verified by the tests that we touched in the previous commits; they ensure that the buttons' checked state still updates visibly. Fixes: zulip#1545

chrisbobbe · 2025-07-08T05:45:16Z

Thanks! Revision pushed.

chrisbobbe requested a review from gnprice June 17, 2025 21:23

chrisbobbe assigned gnprice Jun 17, 2025

chrisbobbe added the integration review Added by maintainers when PR may be ready for integration label Jun 17, 2025

gnprice reviewed Jun 18, 2025

View reviewed changes

gnprice force-pushed the pr-radiogroup-api-migration-again branch 2 times, most recently from ac6c750 to 4d1baae Compare July 3, 2025 18:54

chrisbobbe force-pushed the pr-radiogroup-api-migration-again branch from 4d1baae to ffd094c Compare July 7, 2025 18:59

gnprice reviewed Jul 7, 2025

View reviewed changes

chrisbobbe added 4 commits July 7, 2025 22:44

settings test: Check theme-setting radio buttons by checking semantics

45a2e60

This tests the observable behavior more directly. RadioListTile.checked has been deprecated (zulip#1545), so we'd like this test to stop relying on that implementation detail.

settings test [nfc]: Pull out checkRadioButtonAppearsChecked helper

82dbbfe

settings test: Add widget tests for latest settings

9743cec

"Open message feeds at" and "Mark messages as read on scroll". Related: zulip#1571 Related: zulip#1583

settings: Migrate to new RadioGroup API for radio buttons

5f9512e

This migration is verified by the tests that we touched in the previous commits; they ensure that the buttons' checked state still updates visibly. Fixes: zulip#1545

chrisbobbe force-pushed the pr-radiogroup-api-migration-again branch from ffd094c to 5f9512e Compare July 8, 2025 05:45

	await tester.pump((lastPushedRoute as TransitionRoute).transitionDuration);
	await tester.pump(navObserver.lastTransitionDuration);

	await tester.tap(find.byType(BackButton));
	await tester.tap(find.backButton());

settings: Migrate to new RadioGroup API; write widget tests for two just-added settings #1602

Are you sure you want to change the base?

settings: Migrate to new RadioGroup API; write widget tests for two just-added settings #1602

Uh oh!

Conversation

chrisbobbe commented Jun 17, 2025

Uh oh!

gnprice left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrisbobbe commented Jul 1, 2025

Uh oh!

gnprice commented Jul 2, 2025

Uh oh!

chrisbobbe commented Jul 2, 2025

Uh oh!

gnprice commented Jul 3, 2025

Uh oh!

chrisbobbe commented Jul 7, 2025

Uh oh!

gnprice left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrisbobbe commented Jul 8, 2025

Uh oh!

Uh oh!