With integration_test, we could use these page objects in our integration tests as well, but some modifications had to be made. Generally, it's common to use tester.pumpAndSettle() in unit tests to "finish" your last input (e.g. a tap, a scroll, etc). It tells the test environment to:
- build and render a new frame
- check to see if new frames are scheduled
- repeat until there are no more frames scheduled
This gives a really nice behaviour in unit tests, since network calls are typically mocked and can resolve synchronously (or at the very least before the next frame). It's common for buttons to have subtle animations that may take 10-15 frames that wouldn't be caught by a single tester.pump().
In integration tests, however, if the animation finishes before the network request, the app will have reached stage 3 (no more frames scheduled), and pumpAndSettle() will return, and your test will likely fail. To get around this, our page objects needed a little tweaking. Before migrating, when a page object "tapped" something it would call this:
class PageObject<T extends Widget> {
// fields and other boilerplate
Future<void> tap(dynamic finder) async {
await tester.tap(wrapFinder(finder));
await tester.pumpAndSettle();
}
}
Here, wrapFinder is a utility method that improves ergonimics slightly. It just lets us write page.tap('Event name') instead of page.tap(find.text('Event name')).
This naive approach was fine, as long as any network calls that needed to happen finished within the call to pumpAndSettle. When this wasn't the case, we needed to wait for something to be visible:
Future<void> tap(dynamic finder, {dynamic waitFor}) async {
await tester.tap(wrapFinder(finder));
await tester.pumpAndSettle();
if (waitFor != null && isIntegrationTest) {
// add some delay, then check if waitFor is visible, with some exponential backoff
}
}
Then when we define our page-specific methods, we can pass in a value to waitFor when we know that we want to wait for something. Often, however, we follow a fairly standard pattern of: button press -> wait for network request -> go to new page. For this default case, we can do better! There is a variant of tap called tapAndNavigate, which just performs a tap, then returns a page object for a different page:
Future<PageObject<S>> tapAndNavigate<S extends Widget>(dynamic finder) async {
await tap(finder, waitFor: find.byType(S));
return PageObject(tester); // the type of the new page is inferred here
}
But since we know that, when changing to a new page, we usually want to wait for it to appear (and since Dart supports reified generics), we can simply pass find.byType(S) in to make sure we wait into the new page has appeared.
This doesn't apply everywhere of course, and some methods needed manually overriding, but it helps to narrow the gap between integration tests and widget tests.
All in all, this makes our integration tests just as easy to write as widget tests. For example, here's a widget test for the login page (comments mine):
testWidgets('it should allow a user to log in and log out', (tester) async {
final loginPage = await launchAppLoggedOut(tester);
await loginPage.logInTo<EventsPage>(); // default credentials for mock api here
final appMenu = await pressAppMenuButton(tester);
await appMenu.selectLogOutOption();
await page<LoginPage>(tester); // a helper function to allow async work in "constructors"
});
And now, the corresponding integration test:
integrationTest('should allow logging in and logging out', (tester, commands) async {
final loginPage = await page<LoginPage>(tester);
// "test helper" api available on testing environments, create a real user and return details
final user = await commands.api.createUser();
await loginPage.logIn(user.credentials);
final appMenu = await pressAppMenuButton(tester);
await appMenu.selectLogOutOption();
await page<LoginPage>(tester);
});
