测试插件

所有常见的 Flutter 测试类型也适用于插件包，但由于插件包含原生代码，通常还需要其他类型的测试来测试其全部功能。

要查看每类测试的示例，你可以 从插件模板创建新插件 并查看指定目录。

• Dart 单元测试 和 widget 测试。这些测试允许你测试插件的 Dart 部分，就像测试非插件包的 Dart 代码一样。不过，插件的原生代码不会被加载，因此对平台通道的任何调用都需要在测试中mock。

  请参阅 test 目录中的示例。

• Dart 集成测试。由于集成测试在 Flutter 应用（示例应用）的上下文中运行，它们可以测试 Dart 与原生代码，以及两者之间的交互。它们也适用于对需要在浏览器中运行的 Web 实现代码进行单元测试。

  这些通常是插件最重要的测试。不过，使用 integration_test 的 Dart 集成测试无法与原生 UI 交互，例如原生对话框或 platform view 的内容。如需原生组件交互支持，可考虑使用 patrol

  请参阅 example/integration_test 目录中的示例。

• 原生单元测试。 正如 Dart 单元测试可以隔离测试插件的 Dart 部分，原生单元测试可以隔离测试原生部分。每个平台都有自己的原生单元测试系统，测试使用与被测代码相同的原生语言编写。

  如果你需要 mock 插件代码封装的 API，这在 Dart 集成测试中无法实现，原生单元测试尤其有价值。

  你可以为每个平台设置并使用你熟悉的任何原生测试框架，但以下已在插件模板中配置：

  • Android： JUnit 测试位于 android/src/test/。

  • iOS 和 macOS： XCTest 测试分别位于 example/ios/RunnerTests/ 和 example/macos/RunnerTests/。这些位于示例目录，而非顶层包目录，因为它们通过示例应用的项目运行。

  • Linux 和 Windows： GoogleTest 测试分别位于 linux/test/ 和 windows/test/。

模板中当前未预配置的其他测试类型是 原生 UI 测试。在原生 UI 测试框架下运行应用，例如 Espresso 或 XCUITest，可实现与原生和 Flutter UI 元素交互的测试，因此若插件无法在没有原生 UI 交互的情况下测试，这会很有用。

这些可以像任何其他 Flutter 单元测试一样运行，在你首选的 Flutter IDE 中，或使用 flutter test。

有关运行此类测试的信息，请参阅 集成测试文档。命令必须在 example 目录中运行。

对于所有平台，你需要在运行单元测试前至少构建一次示例应用，以确保所有平台特定的构建文件已创建。

Android JUnit

Android JUnit

如果你在 Android Studio 中将示例作为 Android 项目打开，可以使用 Android Studio 测试 UI 运行单元测试。

要从命令行运行测试，在 example/android 目录中使用以下命令：

./gradlew testDebugUnitTest

iOS 与 macOS XCTest

如果你在 Xcode 中打开了示例应用，可以使用 Xcode 测试 UI 运行单元测试。

要从命令行运行测试，在 example/ios（iOS）或 example/macos（macOS）目录中使用以下命令：

xcodebuild test -workspace Runner.xcworkspace -scheme Runner -configuration Debug

对于 iOS 测试，你可能需要先在 Xcode 中打开 Runner.xcworkspace 以配置代码签名。

Linux GoogleTest

Linux GoogleTest

要从命令行运行测试，在示例目录中使用以下命令，将 "my_plugin" 替换为你的插件项目名称：

build/linux/plugins/x64/debug/my_plugin/my_plugin_test

如果你以 release 模式而非 debug 模式构建示例应用，将 "debug" 替换为 "release"。

Windows GoogleTest

Windows GoogleTest

如果你在 Visual Studio 中打开了示例应用，可以使用 Visual Studio 测试 UI 运行单元测试。

要从命令行运行测试，在示例目录中使用以下命令，将 "my_plugin" 替换为你的插件项目名称：

build/windows/plugins/my_plugin/Debug/my_plugin_test.exe

如果你以 release 模式而非 debug 模式构建示例应用，将 "Debug" 替换为 "Release"。

测试 Flutter 项目的一般建议 也适用于插件。插件测试的一些额外考虑：

• Since only integration tests can test the communication between Dart and the native languages, try to have at least one integration test of each platform channel call.

• 由于只有集成测试可以测试 Dart 与原生语言之间的通信，请尽量为每个平台通道调用至少编写一个集成测试。

• If some flows can't be tested using the integration_test package (for example if they require interacting with native UI or mocking device state), consider using the patrol package for native UI interactions, or writing "end to end" tests of the two halves using unit tests:

• 如果某些流程无法使用 integration_test 包测试（例如需要与原生 UI 交互或 mock 设备状态），可考虑使用 patrol 包进行原生 UI 交互，或使用单元测试为两半编写「端到端」测试：

  • Native unit tests that set up the necessary mocks, then call into the method channel entry point with a synthesized call and validate the method response.

  • 设置必要 mock 的原生单元测试，然后通过合成的调用调用 method channel 入口点并验证方法响应。

  • Dart unit tests that mock the platform channel, then call the plugin's public API and validate the results.

  • mock 平台通道的 Dart 单元测试，然后调用插件的公共 API 并验证结果。