Skip to content

[native assets] [testing] Cleanup fake in tests #162061

@dcharkes

Description

@dcharkes

I stumbled upon some weird looking code in some of our testing fakes:

final BuildResult? Function(BuildConfig)? onBuild;
final LinkResult? Function(LinkConfig)? onLink;

@override
Future<BuildResult?> build({
required List<String> buildAssetTypes,
required BuildConfigValidator configValidator,
required BuildConfigCreator configCreator,
required BuildValidator buildValidator,
required ApplicationAssetValidator applicationAssetValidator,
required Uri workingDirectory,
required bool linkingEnabled,
}) async {
BuildResult? result = buildResult;
for (final Package package in packagesWithNativeAssetsResult) {
final BuildConfigBuilder configBuilder =
configCreator()
..setupHookConfig(
packageRoot: package.root,
packageName: package.name,
buildAssetTypes: buildAssetTypes,
)
..setupBuildConfig(dryRun: false, linkingEnabled: linkingEnabled)
..setupBuildRunConfig(
outputDirectory: Uri.parse('build-out-dir'),
outputDirectoryShared: Uri.parse('build-out-dir-shared'),
);
final BuildConfig buildConfig = BuildConfig(configBuilder.json);
if (onBuild != null) {
result = onBuild!(buildConfig);
}
buildInvocations++;
}
return result;
}

onBuild takes a BuildConfig (single hook invocation), but outputs a BuildResult which is the aggregated of all hook invocations. The implementation then does a loop over all packages and simply overwrites the result if there is more than one package with native assets. Unsurprisingly, we don't have any invocations with more than one package with native assets.

This should be rewritten in one of the two following ways:

  • final BuildOutput? Function(BuildConfig)? onBuild; and loop over all packages and combine the results, or
  • final BuildResult? Function()? onBuild and don't loop over the packages.

If this should be a shallow mock, it should just record what it is invoked with and not do anything fancy. So I'm leaning towards option 2.

cc @mkustermann you added the loop over the packages (presumably to get access to a BuildConfig), any opinions?

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Issues that are less important to the Flutter projectc: tech-debtTechnical debt, code quality, testing, etc.team-toolOwned by Flutter Tool teamtriaged-toolTriaged by Flutter Tool team

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions