Make API logic testable, and start testing some #23
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
chrisbobbe
approved these changes
Mar 7, 2023
test/api/model/events_checks.dart
Outdated
| Subject<Message> get message => has((e) => e.message, 'message'); | ||
| } | ||
|
|
||
| extension HeartbeatEventChecks on Subject<HeartbeatEvent> { |
This is mostly for the sake of starting to exercise FakeApiConnection, though this is functionality that it's probably best to have a test for in any case.
|
Thanks! Merging with that fix. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is motivated just now by #21 by way of a couple of steps of yak-shaving (while #21 is itself yak-shaving for #13 which is for #11.) But it's also something we'll clearly want in any case.
For #21, we'll want some logic where the
GlobalStorekeeps around a collection ofPerAccountStores, and when asked can pull out an existing one or load up a new one as needed. Because the loading is async (it involves talking to the server to fetch initial data; in the future it might start by reading a local snapshot from a database, but that'll also be async), the logic to prevent two concurrent calls from redundantly both doing the work is a bit more than trivial. I wrote up that logic and then figured it should have a test.But the test shouldn't go try to talk to an actual Zulip server. So we'll need a way to swap in a fake implementation of talking to the server, for tests. This gets us part of the way there, far enough to write a few tests to validate that it works.