-
Notifications
You must be signed in to change notification settings - Fork 115
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
Add zulip.test #368
Add zulip.test #368
Conversation
Zulip is an open-source team chat app, with a new Flutter-based mobile client now in beta. This is that client's test suite. I believe these will be the only tests currently in this registry for an app, rather than a library. That should naturally give them a different mix of use cases and types of tests. Concretely, we've seen a handful of breaking changes over the past year that weren't caught by any of Flutter's existing test suites. These were in text hit-testing: zulip/zulip-flutter@ba7a2bf flutter/flutter#140621 and Material menu behavior: zulip/zulip-flutter@38ed6c8 flutter/flutter#130536 and SlottedContainerRenderObjectMixin gaining a type parameter: zulip/zulip-flutter@2f0f469 flutter/flutter#126108 I'm not complaining, to be clear, and none of these were particularly onerous for us to adapt to. By registering these tests, I'm hoping to provide feedback on future such breakages at a point where it's actionable. Omitted here are several tests that re-generate generated files and check they match what's in the tree. Those are pretty slow, and I think they're pretty insensitive to changes in the Flutter tree anyway; rather they depend on pigeon, json_serializable, build_runner, and drift_dev.
These do take longer than the "100 times in 15 minutes" guideline: on my machine, 100 iterations takes about 35 minutes. I don't think they're doing anything especially slow; I think it's just that we have a lot of tests. But naturally please feel free to take a look and make your own judgement. |
I think this may be the first time our tests have ever been run on Windows. 😅 There's one failure, which I've just sent a fix for: I'll update this PR once that's merged. |
There's also a failure in
It looks like there's active work on flutter/flutter#148348, so I'll assume this is a flake and let that issue track fixing its cause. |
Hmm, still failing on Windows (and still passing on Linux and macOS). But I'm puzzled at the remaining failure:
So the output of both |
Looking around at other suites in the registry: Several don't run on Windows: flutter_svg, flutter_devtools, flutter_cocoon. (And macos_ui is disabled entirely.) Among those that do run, dart_rfb has exactly the same two
but there's no "ERROR: One or more tests from zulip failed." line, and the suite passes. In particular, that one has a skipped test too, so it's not like somehow having a skip is causing the failure. I don't really have any other ideas. I looked at So if anyone has ideas for why Failing that, my inclination would be to use |
OK, skipped Windows. All tests are now passing. |
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.
Zulip is an open-source team chat app, with a new Flutter-based mobile client now in beta. This is that client's test suite.
I believe these will be the only tests currently in this registry for an app, rather than a library. That should naturally give them a different mix of use cases and types of tests.
Concretely, we've seen a handful of breaking changes over the past year that weren't caught by any of Flutter's existing test suites. These were in text hit-testing:
zulip/zulip-flutter@ba7a2bf
flutter/flutter#140621
and Material menu behavior:
zulip/zulip-flutter@38ed6c8
flutter/flutter#130536
and SlottedContainerRenderObjectMixin gaining a type parameter:
zulip/zulip-flutter@2f0f469
flutter/flutter#126108
I'm not complaining, to be clear, and none of these were particularly onerous for us to adapt to. By registering these tests, I'm hoping to provide feedback on future such breakages at a point where it's actionable.
Omitted here are several tests that re-generate generated files and check they match what's in the tree. Those are pretty slow, and I think they're pretty insensitive to changes in the Flutter tree anyway; rather they depend on pigeon, json_serializable, build_runner, and drift_dev.