Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

withClock() behaves inconsistently with test() #17

Closed
jamesderlin opened this issue May 8, 2020 · 2 comments
Closed

withClock() behaves inconsistently with test() #17

jamesderlin opened this issue May 8, 2020 · 2 comments

Comments

@jamesderlin
Copy link

jamesderlin commented May 8, 2020

Consider this code:

import 'package:clock/clock.dart';
import 'package:test/test.dart';

void main() {
  final fakeClock = Clock.fixed(DateTime(2020, 1, 1));

  test('inner withClock', () {
    withClock(fakeClock, () {
      expect(clock, same(fakeClock));
    });
  });

  withClock(fakeClock, () {
    test('outer withClock', () {
      expect(clock, same(fakeClock));
    });
  });
}

I don't see anything in the withClock documentation that indicates whether one form is preferred over the other. When I run this with dart this_test.dart, I get:

00:00 +0: inner withClock
00:00 +1: outer withClock
00:00 +1 -1: outer withClock [E]

  Expected: same instance as <Instance of 'Clock'>
    Actual: <Instance of 'Clock'>

More weirdness, part 1

If I reverse the tests, they pass when running it through dart.

More weirdness, part 2

The "outer withClock" test by itself fails with flutter test or with pub run test. Each test passes individually when run directly through dart.

Ultimately I'd like to do:

withClock(fakeClock, () {
  test(...);
  test(...);
  test(...);
});

but all of this weirdness seems to prevent that.

(I'm using Dart 2.8.1 with clock 1.0.1.)

@jamesderlin
Copy link
Author

I think that this is dart-lang/test#1023. The test callbacks don't run in the same Zone as when test() was executed.

@jamesderlin
Copy link
Author

I still don't understand how the "outer withClock" test ever works at all, but I care a lot less about that knowing that I shouldn't expect it to work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant