Navigation Menu

Skip to content

Instantly share code, notes, and snippets.

Created May 16, 2023 12:56
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save bartekpacia/642f043bfbb938126f587f3ebfd5c6ac to your computer and use it in GitHub Desktop.
Save bartekpacia/642f043bfbb938126f587f3ebfd5c6ac to your computer and use it in GitHub Desktop.
File generated by Patrol CLI for the "integration_test" directory with 2 test files.
// ignore_for_file: invalid_use_of_internal_member,
// depend_on_referenced_packages, directives_ordering
import 'dart:async';
import 'package:flutter_test/flutter_test.dart';
import 'package:patrol/patrol.dart';
import 'package:patrol/src/native/contracts/contracts.pbgrpc.dart';
import 'package:test_api/src/backend/invoker.dart';
import 'notifications_test.dart' as notifications_test;
import 'permissions_location_test.dart' as permissions_location_test;
Future<void> main() async {
final nativeAutomator = NativeAutomator(config: NativeAutomatorConfig());
final binding = PatrolBinding.ensureInitialized();
// This is the entrypoint of the bundled Dart test.
// Its responsibilies are:
// * Run a special Dart test that explores the hierarchy of groups and tests,
// so it can...
// * ... host a service that the native side of Patrol uses to get the list
// of Dart tests, and to request execution of a specific Dart test.
// When running on Android, the Android Test Orchestrator, before running the
// tests, makes an initial run to gather the tests that it will later run. The
// native side of Patrol (specifically: PatrolJUnitRunner class) is hooked
// into the Android Test Orchestrator lifecycle and knows when that initial
// run happens. When it does, PatrolJUnitRunner makes an RPC call to
// PatrolAppService and asks it for the list of Dart tests.
// When running on iOS, the native side of Patrol (specifically: the
// PatrolAppSevice and asks it for the list of Dart tests.
// Once the native runner has the list of Dart tests, it dynamically creates
// native test cases from them. On Android, this is done using the
// Parametrized JUnit runner. On iOS, new test case methods are swizzled into
// the RunnerUITests class, taking advantage of the very dynamic nature of
// Objective-C runtime.
// Execution of these dynamically created native test cases is then fully
// managed by the underlying native test framework (JUnit on Android, XCTest
// on iOS).
// The native test cases do only one thing - request execution of the Dart
// test (out of which they had been created) and wait for it to complete.
// The result of running the Dart test is the result of the native test case.
final testExplorationCompleter = Completer<DartTestGroup>();
// A special test to expore the hierarchy of groups and tests. This is a
// hack around
// This test must be the first to run. If not, the native side likely won't
// receive any tests, and everything will fall apart.
test('patrol_test_explorer', () {
final topLevelGroup = Invoker.current!.liveTest.groups.first;
final dartTestGroup = createDartTestGroup(topLevelGroup);
group('notifications_test', notifications_test.main);
group('permissions_location_test', permissions_location_test.main);
final dartTestGroup = await testExplorationCompleter.future;
final appService = PatrolAppService(topLevelDartTestGroup: dartTestGroup);
binding.patrolAppService = appService;
await runAppService(appService);
// Until now, the native test runner was waiting for us, the Dart side, to
// come alive. Now that we did, let's tell it that we're ready to be asked
// about Dart tests.
await nativeAutomator.markPatrolAppServiceReady();
await appService.testExecutionCompleted;
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment