Refactorings to testbed.run and testbed.test#44488
Refactorings to testbed.run and testbed.test#44488jonahwilliams merged 1 commit intoflutter:masterfrom
Conversation
fluttergithubbot
added
the
tool
|
One of the situations I want to avoid in a post NNBD world: |
|
|
||
| test('Can run a build', () => testbed.run(() async { | ||
| when(mockBuildSystem.build(any, any, buildSystemConfig: anyNamed('buildSystemConfig'))) | ||
| testbed.test('Can run a build', () async { |
There was a problem hiding this comment.
For my own understanding, how is testbed different than using testUsingContext?
There was a problem hiding this comment.
Testbed allows you to supply a setup function which is invoked in the same Zone that the test case is run in. This means that the zone injected values will be exactly the same (logger, fs, buildSystem).
The only way to do this setup with test usingContext is to use top levels initialized in setup and the test case. This requires plumbing values between various setup functions and the test callbacks, which is where nullability issues creep in.
There was a problem hiding this comment.
Additionally, running it in the same zone allows you to use the same affordances for setup that you would otherwise use for programming. Example:
before
FileSystem fileSystem;
setUp(() {
fileSystem = MemoryFileSystem(fileSystemStyle: ...);
fileSystem.file('a').createSync();
});
testUsingContext('a exists', () {
expect(fs.file('a).existsSync(), true);
}, overrides: <Type, Generator>{
FileSystem: () => fileSystem,
}
after
Testbed testbed = Testbed(setup: () {
fs.file('a').createSync();
});
testbed.test('a exists, () {
expect(fs.file('a).existsSync(), true);
});
5 participants
Description
Attempts to reduce testing and simplify how tests are declared and setup, especially in the presence of NNBD. Changes:
(1) Create testbed in main instead of setup. Rationale: creating a testbed does not perform any additional work beyond object creation. Moving into setup to avoid work for the case where we only want to run a single test doesn't buy us much, and would force us to either declare testbed as
lateornullable- both of which introduce potential for runtime exceptions and overhead.(2) Remove top level fields referenced in
setUp. The mockito APIs do not require access to instance itself - we can use the typed context getters instead.(3) Remove nested closure and provide test method on testbed itself. Reduces nesting, looks cleaner, and no regression in functionality due to annotation. Requires (1).
If this seems like a nicer approach to take, I'll convert the reset of the APIs and remove
run.