Skip to content

Conversation

@chrisbobbe
Copy link
Collaborator

@chrisbobbe chrisbobbe commented Nov 14, 2025

The main work here is to change several tests of MessageListView and MessageStore so that the channels they exercise are actually known (i.e. present in the store) and subscribed, which we can consider the boring, common case. Without this change, some of these tests would fail when we change the behavior for unsubscribed channels, for #1798.

Compare d6f2441 and f89ce2e, where we similarly changed the setup for various widget tests, also to prepare for #1798.

Related: #1798

In all of these tests, the message list's narrow is a ChannelNarrow,
and all of the deleted messages are in that channel. The tests
aren't about whether or not the deleted messages are in the message
list's narrow; really they're about whether or not the deleted
messages are present in the MessageListView model.
Before this, in all the tests touched here, we were exercising the
message list with a channel that isn't actually in the
PerAccountStore. When we don't pass `stream` to the `prepare`
function, the function adds a *different* channel to the store, with
a corresponding Subscription, having streamId
eg.defaultStreamMessageStreamId.

The normal, boring setup, which is suitable for all these tests, is
to exercise the message list in a known, subscribed channel. Provide
that setup by passing the same `stream` object to `prepare` that we
use to create messages and narrows.
…boring

The `prepare` helper, and now the prepare-outbox helpers, fall back
to this channel ID when a different one isn't specified. That's
sensible and lets these tests be a bit more compact.

When tests use two different channels, with pairs of variables like
`stream` and `otherStream`, or `stream1` and `stream2`, I let that
be, even though it might be reasonable for some of them to use
eg.defaultStreamMessageStreamId for one of the channels.
This is the boring, common case that makes sense to exercise here.
@chrisbobbe chrisbobbe added the maintainer review PR ready for review by Zulip maintainers label Nov 14, 2025
Copy link
Member

@rajveermalviya rajveermalviya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @chrisbobbe! LGTM, moving over to Greg's review.

@rajveermalviya rajveermalviya added integration review Added by maintainers when PR may be ready for integration and removed maintainer review PR ready for review by Zulip maintainers labels Nov 17, 2025
@rajveermalviya rajveermalviya requested review from gnprice and rajveermalviya and removed request for rajveermalviya November 17, 2025 17:43
Copy link
Member

@gnprice gnprice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! A couple of comments below.

Comment on lines 306 to +318
test('some messages found in fetch; outbox messages present', () => awaitFakeAsync((async) async {
final stream = eg.stream();
await prepare(
narrow: eg.topicNarrow(stream.streamId, 'topic'), stream: stream);
narrow: eg.topicNarrow(eg.defaultStreamMessageStreamId, 'topic'));

await prepareOutboxMessages(count: 1, stream: stream, topic: 'topic');
await prepareOutboxMessages(count: 1, topic: 'topic');
async.elapse(kLocalEchoDebounceDuration);
checkNotNotified();
check(model)
..fetched.isFalse()
..outboxMessages.isEmpty();

connection.prepare(json: newestResult(foundOldest: true,
messages: [eg.streamMessage(stream: stream, topic: 'topic')]).toJson());
messages: [eg.streamMessage(topic: 'topic')]).toJson());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't love this part of the changes:
c3a58ac msglist test: Switch to using eg.defaultStreamMessageStreamId, where boring

It's true that it makes the tests somewhat more compact. But it introduces an implicit relationship between eg.streamMessage, the behavior of prepareOutboxMessages, and the narrow prepared above. The specific stream/channel involved is indeed boring — but the fact that they're all referring to the same stream/channel is essential for understanding the test. That fact is explicit in the current version of this test and becomes implicit with this change.

(Similarly in most of the other test cases, I think.)

So my inclination would be to drop these commits:
31c85e9 msglist test [nfc]: Have prepare-outbox helpers take channel ID not channel
b241fc0 msglist test [nfc]: Support omitting channelId in prepare-outbox helpers
c3a58ac msglist test: Switch to using eg.defaultStreamMessageStreamId, where boring
82733ca message test: Switch to using eg.defaultStreamMessageStreamId, where boring

while keeping these commits:
68f3269 msglist test [nfc]: Fix some test descriptions
fe60009 msglist test: Switch some model tests to use subscribed channels
65e0f67 message test: Use known, subscribed channel in sendMessage smoke test

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The existing usage of eg.defaultStreamMessageStreamId which I'm happier about is where the test doesn't really refer to a stream/channel at all, and just needs a message that will appear in the message list. For example:

    testWidgets('content not asked to consume insets (including bottom), even without compose box, in bottom sliver', (tester) async {
      // …
      await setupMessageListPage(tester, narrow: const CombinedFeedNarrow(),
        messages: [eg.streamMessage(content: ContentExample.codeBlockPlain.html)]);

Typically, like in that example, these tests choose the maximally-boring narrow of CombinedFeedNarrow; and then for the message to appear requires that it be to a subscribed channel, but the test doesn't really call for thinking about that detail, so we have setupMessageListPage use eg.defaultStreamMessageStreamId to arrange for that behind the scenes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

integration review Added by maintainers when PR may be ready for integration

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants