The didPop, didRemove, and didReplace methods in _ClosureNavigatorObserver use the null-assertion operator (!) on previousRoute and newRoute. While the current test scenario might not trigger a null value for previousRoute or newRoute, these methods are general NavigatorObserver callbacks and previousRoute can legitimately be null (e.g., when the last route is popped). Using ! here could lead to runtime errors in other test cases where these routes might be null. It's safer to handle the nullable routes explicitly before passing them to onDidChange.

  @override
  void didPop(Route<dynamic> route, Route<dynamic>? previousRoute) {
    if (previousRoute != null) {
      onDidChange(previousRoute);
    }
  }

  @override
  void didRemove(Route<dynamic> route, Route<dynamic>? previousRoute) {
    if (previousRoute != null) {
      onDidChange(previousRoute);
    }
  }

  @override
  void didReplace({Route<dynamic>? newRoute, Route<dynamic>? oldRoute}) {
    if (newRoute != null) {
      onDidChange(newRoute);
    }
  }

Looks like we do this same pattern elsewhere.

I'm of the opinion that for this test case it's fine that this would throw an error if the route is null for this case, as it shouldn't be null and it might catch an issue with later PRs.

Looks like we do this same pattern elsewhere.

I'm of the opinion that for this test case it's fine that this would throw an error if the route is null for this case, as it shouldn't be null and it might catch an issue with later PRs.