Skip to content
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

Make PerAccountStoreWidget usage testable #30

Closed
gnprice opened this issue Mar 18, 2023 · 0 comments · Fixed by #176
Closed

Make PerAccountStoreWidget usage testable #30

gnprice opened this issue Mar 18, 2023 · 0 comments · Fixed by #176
Assignees
Labels
a-model Implementing our data model (PerAccountStore, etc.) a-tests
Milestone

Comments

@gnprice
Copy link
Member

gnprice commented Mar 18, 2023

We'll want to write tests for many of our widgets. A number of our widgets refer to PerAccountStoreWidget.of(context) to get their data, and we'll want to test many of those. So to do this, we'll need something a test can do to provide a PerAccountStoreWidget based on self-contained data chosen by the test.

I think the core of this will be what I mentioned in 882c8ae :

Widgets still hardcode the "live" GlobalStore, so we'll need
to make some further changes when we go to write tests for those
widgets.

That refers mainly to this line in the implementation of GlobalStoreWidget:

      final store = await LiveGlobalStore.load();

I think the solution here will probably be to take inspiration from the "binding" concept in Flutter itself, as in WidgetsFlutterBinding vs. TestWidgetsFlutterBinding, and explained more at BindingBase. I wouldn't try to integrate directly into that system, I think, but build something small and analogous to it.

This would look something like:

abstract class DataBinding {
  static DataBinding get instance => // …

  Future<GlobalStore> loadGlobalStore();
}

class LiveDataBinding extends DataBinding {
  static DataBinding ensureInitialized() {
    // …
  }

  // …
}

and then

  • the main function in lib/main.dart calls LiveDataBinding.ensureInitialized() before it calls runApp;
  • GlobalStoreWidget's implementation would say final store = await DataBinding.instance.loadGlobalStore();.

Meanwhile, in the test code, there'd be:

class TestDataBinding extends DataBinding // …

and our widget tests would call a TestDataBinding.ensureInitialized() instead.

Or something like that. Will have to start writing the code and see where it takes us.

@gnprice gnprice added a-model Implementing our data model (PerAccountStore, etc.) a-tests labels May 27, 2023
@gnprice gnprice added this to the Alpha milestone Jun 7, 2023
@gnprice gnprice self-assigned this Jun 12, 2023
gnprice added a commit to gnprice/zulip-flutter that referenced this issue Jun 12, 2023
This indirection will be useful as a customization point
for use in tests.

This provides the core of zulip#30: uses of PerAccountStoreWidget are now
testable, in that subsequent commits in this series will start writing
such tests and won't require any further changes in lib/, only test/.
gnprice added a commit to gnprice/zulip-flutter that referenced this issue Jun 12, 2023
We previously had a class called TestGlobalStore, but it's a bit
specialized for the use case of testing GlobalStore itself.

This provides all the infrastructure we'll need in order to start
writing individual tests as part of zulip#30.
gnprice added a commit to gnprice/zulip-flutter that referenced this issue Jun 12, 2023
This gives us our first concrete tests of application code that uses
PerAccountStoreWidget, so zulip#30 is complete.

Fixes: zulip#30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a-model Implementing our data model (PerAccountStore, etc.) a-tests
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant