как восстановить FlutterError.onError?

Question

В моем приложении я записываю трепетание на ошибку при сбое,

      FlutterError.onError = FirebaseCrashlytics.instance.recordFlutterError;

Во время выполнения интеграционного теста, если возникают какие-то исключения, я получаю в консоли следующий оператор, и тест просто зависает,

При выполнении теста возникло следующее исключение: I / flutter (30479): тест переопределил FlutterError.onError, но либо не смог вернуть его в исходное состояние, либо имел непредвиденные дополнительные ошибки, которые он не мог обработать. Обычно это вызвано использованием expect() перед восстановлением FlutterError.onError.

Приведенное выше сообщение в консоли предполагает, что что-то не так с преобладающий, как мне вернуться в исходное состояние согласно рекомендации, появляющейся в консоли.

Обратите внимание, что я использую только что рекомендованный способ для интеграционного теста ,

Answer 1

является общедоступным статическим членом FlutterError, так что технически его может переопределить кто угодно и откуда угодно. testWidgets()сама функция также переопределяет с помощью собственного обработчика ошибок перед запуском тела теста. Вы можете прочитать его исходный код для получения дополнительной информации.

В основном, ниже то, что произошло:

      testWidgets('', (tester) async { // onError is overridden with the handler of the test framework
  await app.main(); // onError is overridden again with crashlytics error handler
  //...
  expect(); // Flutter yells that you should have not touched its onError
});

Дело в том, что тестовая среда Flutter нуждается в своем onErrorработать должным образом. Поэтому, что бы вы ни делали, не забудьте вызвать обработчик ошибок тестовой среды.

Ниже приведен способ, который я использовал в своем проекте для «восстановления» FlutterError.onError(и сделать что-то еще):

      testWidgets('', (tester) async {
  final originalOnError = FlutterError.onError!;
  FlutterError.onError = (FlutterErrorDetails details) {
    // do something like ignoring an exception
    originalOnError(details); // call test framework's error handler
  };
  // ...
  expect();
});

С некоторыми изменениями, я думаю, ваша проблема решаема.

Answer 2

Эта вспомогательная функция, которую я написал, работает для меня:

      
Future<void> restoreFlutterError(Future<void> Function() call) async {
  final originalOnError = FlutterError.onError!;
  await call();
  final overriddenOnError = FlutterError.onError!;

  // restore FlutterError.onError
  FlutterError.onError = (FlutterErrorDetails details) {
    if (overriddenOnError != originalOnError) overriddenOnError(details);
    originalOnError(details);
  };
}

void main(){
  testWidgets("some test", (tester) async {
    await restoreFlutterError(() async {
      app.main();
      await tester.pumpAndSettle();
    });
    // ...
    expect(...);
  });
}

Все, что переопределяетFlutterError.onErrorможно обернуть вокругrestoreFlutterError- функция следит за тем, чтобы обаonErrorобработчик (ваш и установленный тестовой средой).

Answer 3

хм, хорошо ... похоже, у нас есть пара проблем, связанных с этим 🤔: ссылка-1, ссылка-2, ссылка-3

Короче говоря: кажется, что библиотека пока оптимизирована только для "счастливых путей".

В моем случае Firebase конфликтовала с integration_test когда эта строка была включена:

         FirebaseMessaging.onBackgroundMessage(_onBackgroundOrTerminatedHandler);

Ошибка исчезла, как только я отключил ее (при запуске интеграционных тестов).

Answer 4

Я видел эту ошибку, потому что забыл позвонитьawait tester.pumpAndSettle()после того, как попросите тест нажать кнопку.

Это предотвратило переход приложения на следующий экран. Когда я попытался найти конкретное TextField, оно не было видно для интеграционного теста.

Причина ошибки в моем случае не имела ничего общего с необходимостью восстановления FlutterError.onError.

Answer 5

Попробуйте обновить до флаттера 2.5.0. Там это вроде исправлено.

Он больше не зависает при запуске теста. Таким образом, он продолжает выполнять остальные тесты. Хотя он по-прежнему показывает _pendingExceptionDetails != nullошибка