Patrol Next

[bartekpacia]

TL;DR

This issue tracks the architectural redesign of Patrol. The redesign is required to be able to circumvent longstanding issues with Flutter described here.

All your tests written using Patrol will continue to work.

The redesign will be almost completely seamless from the developer/tester perspective – it'll take place only under the hood. Some minor configuration changes might be required, like changing a line in pubspec.yaml or in app's native files, but that's it. So don't worry! :)

Patrol Next

Synopsis

Patrol Next is the codename for Patrol's architecture redesign, which aims to enable features which are impossible to implement with the current architecture.

• the ability to run on Firebase Test Lab, Amazon Device Farm, Browserstack, and similar device farm tools.

  Issues unblocked/resolved:

  • Using Patrol on Firebase Test Lab #332
  • Run in Device Farm Tools #622

• the ability to get native test reports (just like package:integration_test does)

  The native test report formats generated by Xcode and Gradle are widely used and easily converted to other formats.

  Issues unblocked/resolved:

  • Generating test coverage, just like flutter test integration_test does #611
  • Use flutter test instead of flutter drive #421 (we'll have our own test runner, and won't use flutter test, nor flutter drive)

Requirements

1. Works on {virtual, physical} {android, ios} devices
2. Tests are reported natively
3. Debuggability of integration tests in VS Code (attaching to running app)
4. Being able to build all tests into a single app binary (see here)

Roadmap

• initial basic Proof of Concept of the new architectural approach (see POC: Patrol Next #646)

• replicate integration_test functionality 1:1, but include Patrol-only goodies (native UI automation)

• • Decide what to do with native automation code being duplicated twice
• • Update CI workflows

  We will convert the patrol package to patrol plugin. It'll look similar to the integration_test plugin. Setup instructions will be roughly similar.

  Once this step is done, users will be able to import it and use it.

In the future/TBD:

• an extensible Patrol Test Runner, written in Dart, which can be embedded in the integration test and in the CLI

See also:

• integration_test plugin (Android) (iOS)

Workshop notes

Implementation idea

There is a single app, which bundles Flutter AUT (app under test) and native integration test together. Communication between AUT and native integration is accomplished using method channels*.

*After research conducted in #646 we've learned that method channels can only be directly used on Android, because on Android AUT test and integration test run in the same process. This is not the case on iOS, where AUT and instrumentation run in separate processes, so some form of RPC is needed. In #646 eDistantObject library was used for it, but it could be anything. We should find a solution that doesn't differ too much between Android and iOS, to avoid unnecessary work.

Legend:

• PTR = Patrol Test Runner

[neiljaywarner]

sounds fantastic! :)

[neiljaywarner]

@bartekpacia how difficult would it be to use the poc in a hackathon on january 6th, and/or how close will it be to be usable by january 6th? :)

[bartekpacia]

@neiljaywarner No guarantees, but it should be ready by then (ready as in: done 1. and 2. from the "roadmap") :)

[bartekpacia]

This phase is completed.

Migration progress of features from patrol drive to patrol test is tracked in #788.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar problem, please file a new issue. Make sure to follow the template and provide all the information necessary to reproduce the issue.