Skip to content
Boring Doc
BreakingHigh impactOfficial migration guidesince 1.20.0landed 1.18.0

TestWidgetsFlutterBinding.clock

Framework · Official source

The `TestWidgetsFlutterBinding.clock` now comes from `package:clock` and not `package:quiver`.

Original behavior

The `flutter_test` package is removing its dependency on the heavier weight `quiver` package in favor of a dependency on two more targeted and lighter weight packages, `clock` and `fake_async`.

New behavior

Not stated in the source.

Who is affected
Applications and packages relying on the previous behaviour or signature. Code that uses TestWidgetsFlutterBinding.clock, TestWidgetsFlutterBinding, Clock.
Practical impact
Behaviour or API differences that can break builds or change runtime behaviour.
What action should I take?
Follow the official migration guide below, update affected call sites, run `dart fix --apply` where a fix is available, then run your tests.

Before and after (from the official guide)

dart+1−1
Before
1 testWidgets('some test', (WidgetTester tester) {
2− someApiThatWantsAQuiverClock(tester.binding.clock);
3 });
After
1 testWidgets('some test', (WidgetTester tester) {
2+ someApiThatWantsAQuiverClock(Clock(tester.binding.clock.now));
3 });
Raw before / after
testWidgets('some test', (WidgetTester tester) {
  someApiThatWantsAQuiverClock(tester.binding.clock);
});
testWidgets('some test', (WidgetTester tester) {
  someApiThatWantsAQuiverClock(Clock(tester.binding.clock.now));
});
Migration checklist0/2
Official migration guide (excerpt, © The Flutter Authors, CC BY 3.0)

The error you might see after this change looks something like this:

Error: The argument type 'Clock/*1*/' can't be assigned to the parameter type 'Clock/*2*/'.
 - 'Clock/*1*/' is from 'package:clock/src/clock.dart' ('<pub-cache>/clock/lib/src/clock.dart').
 - 'Clock/*2*/' is from 'package:quiver/time.dart' ('<pub-cache>/quiver/lib/time.dart').

Option #1: Create a package:quiver Clock from a package:clock Clock

The easiest migration is to create a package:quiver clock from the package:clock clock, which can be done by passing the .now function tearoff to the Clock constructor:

Code before migration:

testWidgets('some test', (WidgetTester tester) {
  someApiThatWantsAQuiverClock(tester.binding.clock);
});

Code after migration:

testWidgets('some test', (WidgetTester tester) {
  someApiThatWantsAQuiverClock(Clock(tester.binding.clock.now));
});

Option #2: Change the api to accept a package:clock Clock

If you own the api you are calling, you may want to change it to accept a Clock from package:clock. This is a judgement call based on how many places are calling this API with something other than a clock retrieved from a TestWidgetsFlutterBinding.

If you go this route, your call sites that are passing tester.binding.clock won't need to be modified, but other call sites will.

Option #3: Change the API to accept a DateTime function()

If you only use the Clock for its now function, and you control the API, then you can also change it to accept that function directly instead of a Clock. This makes it easily callable with either type of Clock, by passing a tearoff of the now method from either type of clock:

Calling code before migration:

testWidgets('some test', (WidgetTester tester) {
  someApiThatWantsAQuiverClock(tester.binding.clock);
});

Calling code after migration:

testWidgets('some test', (WidgetTester tester) {
  modifiedApiThatTakesANowFunction(tester.binding.clock.now);
});
Migration assistantAI-generated · grounded in cited sources
AI explanations are not configured
Set AI_PROVIDER (for example to openai-compatible with a local Ollama or LM Studio endpoint) to enable grounded explanations. Everything else on this page works without an AI provider.
Official migration guide·Verified classification (95%)

Listed in the official breaking-changes index (docs.flutter.dev/release/breaking-changes).

An official announcement or migration guide documents an intended behaviour or API change. A verified source change (git diff) shows code changed but does not by itself prove a public API is breaking. AI interpretations are labelled and never used to classify a change.

Source commit
b3045439b7c0
Source last updated
Oct 21, 2026
Last synchronized
Oct 21, 2026
Publication status
published
Publication history
  • Oct 21, 2026, 8:31 PM: new → published (ingestion) — Backed by an official breaking-change/migration guide.
AI explanationAI-generated · grounded in cited sources
AI explanations are not configured
Set AI_PROVIDER (for example to openai-compatible with a local Ollama or LM Studio endpoint) to enable grounded explanations. Everything else on this page works without an AI provider.
Was this useful?