-
Notifications
You must be signed in to change notification settings - Fork 358
Use known, subscribed channels in more tests (prep for #1798) #1988
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Use known, subscribed channels in more tests (prep for #1798) #1988
Conversation
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.
rajveermalviya
left a comment
There was a problem hiding this 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.
gnprice
left a comment
There was a problem hiding this 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.
| 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()); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
The main work here is to change several tests of
MessageListViewandMessageStoreso 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