I didn't notice this earlier, why would you need to provide a className if you already provide the object itself? Should the ObjectCreated uses the object.runtimeType if it needs the class name?

runtimeType is different from type that owns instrumentation, because runtime type can be descender (like MaterialPageRoute). Does it help?

thanks for explanation

Nit: why is Route<$T> a clearer name than MaterialPageRoute? I would have thought the more specific class name would be clearer for someone debugging.

Sorry I have not brought up this earlier. Should these logic be wrapped in an assert?

It is proven that this code is tree-shaked when kFlutterMemoryAllocationsEnabled is false, because it is a compile time constant.
So, it is ok to go without assert.
Does this answer your question?

yes, thanks for explanation

you can do

nav.currentState!.push(MaterialPageRoute(builder: (_) => const PlaceHolder())); // This should create a route
await tester.pumpAndSettle();

nav.currentState!.pop();
await tester.pumpAndSettle(); // this should dispose the route.

nav.currentState is null on first line
Did i miss something?

you will need this first before push

await tester.pumpWidget(
      MaterialApp(
        navigatorKey: nav,
        home: const Scaffold(
          body: Text('home'),
        )
      )
    );

Applied. Thank you!

This is interesting, I would expect 3 events. One for MaterialPageRoute created from home page of MaterialApp. Two for creating and disposing the TestPage

ah nvm, the home page will create MaterialPageRoute which will be filter out in the listener

yes!