示例工程教程后端【免费下载链接】aws-doc-sdk-examplesWelcome to the AWS Code Examples Repository. This repo contains code examples used in the AWS documentation, AWS SDK Developer Guides, and more. For more information, see the Readme.md file below.项目地址https://gitcode.com/gh_mirrors/aw/aws-doc-sdk-examples点击查看免费下载本指南以 AWS 代码示例仓库 steering_docs/kotlin-tech/tests.md 为骨架系统讲解如何为 AWS SDK for Kotlin 代码示例生成单元测试Unit Test、集成测试Integration Test与场景测试Scenario Test。读者将掌握 JUnit 5 MockK Coroutines Testing 的完整测试工程搭建方法、三种测试模式的代码范式、Gradle 测试任务隔离配置以及本仓库kotlin/services目录下真实测试文件的落地实践可直接套用于任意 AWS 服务的示例代码测试编写。文档定位与适用范围steering_docs/kotlin-tech/tests.md是aws-doc-sdk-examples仓库中面向 Kotlin 技术线的测试生成规范文档与 steering_docs/kotlin-tech 目录下的其他技术指引架构、代码生成、文档等配套使用。它服务于仓库根目录下 kotlin/services 中按服务划分的示例模块如apigateway、sqs、dynamodb、s3等 50 个 AWS 服务目录每个模块都遵循src/main存放 Action 代码 src/test存放测试代码的标准 Gradle 工程布局。本文档确立的测试生成目标包括使用JUnit JupiterJUnit 5编写全部测试使用MockK对 AWS SDK 客户端进行 mock支撑单元测试使用kotlinx-coroutines-test测试 suspend 函数在测试中使用完整的 AWS 数据结构而非精简字段使用JUnit Tags对测试分类unit / integration覆盖规范中要求的全部错误条件。测试生成前的强制前置步骤知识库查询文档将知识库咨询Knowledge Base Consultation列为任何代码生成之前必须完成的第一步并强调未完成知识库咨询将导致错误的代码结构FAILURE TO COMPLETE KNOWLEDGE BASE CONSULTATION WILL RESULT IN INCORRECT CODE STRUCTURE。该流程包含四个强制步骤# Step 1: List available knowledge bases ListKnowledgeBases() # Step 2: Query coding standards (REQUIRED) QueryKnowledgeBases(coding-standards-KB, Kotlin-code-example-standards) # Step 3: Query implementation patterns (REQUIRED) QueryKnowledgeBases(Kotlin-premium-KB, Kotlin implementation patterns testing) # Step 4: AWS service research (REQUIRED) search_documentation(What is [AWS Service] and what are its key API operations?) read_documentation(https://docs.aws.amazon.com/[service]/latest/[relevant-page])其中第 4 步要求先检索目标 AWS 服务的关键 API 操作再阅读对应官方文档页面。这一步骤的意义在于只有先明确服务的核心 API例如 S3 的CreateBucket/PutObject/GetObjectDynamoDB 的CreateTable/PutItem/Query测试中的 Arrange/Act/Assert 结构与 mock 粒度才能与真实 SDK 模型对齐。测试文件目录结构文档规定每个服务的测试文件统一放置在kotlin/services/{service}/src/test/kotlin/下并按下表约定划分三类文件kotlin/services/{service}/src/test/kotlin/ ├── {Service}ActionsTest.kt # Unit tests for actions ├── {Service}IntegrationTest.kt # Integration tests └── {Service}ScenarioTest.kt # Scenario tests其中{Service}与{service}为占位符按实际服务名替换例如服务为sqs时对应SQSTest.kt为apigateway时对应APIGatewayTest.kt。这与仓库中现有测试文件的命名习惯一致例如 kotlin/services/sqs/src/test/kotlin/SQSTest.kt、kotlin/services/apigateway/src/test/kotlin/APIGatewayTest.kt、kotlin/services/dynamodb/src/test/kotlin/DynamoDB.kt。仓库实际命名略有弹性部分文件直接以服务名命名而非严格ActionsTest后缀但Actions / Integration / Scenario三类测试的职责划分完全一致。Gradle 测试配置build.gradle.kts 依赖与任务隔离推荐的依赖声明模板文档给出了标准化的build.gradle.kts配置核心要点是在依赖中区分 AWS SDK 主依赖与测试依赖并通过tasks.test与自定义integrationTest任务实现单元测试 / 集成测试的隔离plugins { kotlin(jvm) version 1.9.10 application } dependencies { // AWS SDK implementation(aws.sdk.kotlin:{service}:1.0.0) implementation(org.jetbrains.kotlinx:kotlinx-coroutines-core:1.7.3) // Test Dependencies testImplementation(org.jetbrains.kotlin:kotlin-test-junit5) testImplementation(org.junit.jupiter:junit-jupiter-engine:5.10.0) testImplementation(io.mockk:mockk:1.13.8) testImplementation(org.jetbrains.kotlinx:kotlinx-coroutines-test:1.7.3) } tasks.test { useJUnitPlatform() exclude(**/*IntegrationTest*) } tasks.registerTest(integrationTest) { useJUnitPlatform() include(**/*IntegrationTest*) group verification description Runs integration tests }逐项拆解该配置的核心作用kotlin(jvm)Kotlin JVM 插件version可按需升级仓库实际使用的版本见下文aws.sdk.kotlin:{service}:1.0.0目标 AWS 服务的 Kotlin SDK 依赖需替换为具体服务名与版本号kotlinx-coroutines-core主代码与测试共用的协程运行时kotlin-test-junit5提供kotlin.test命名空间下的断言assertEquals、assertNotNull、assertTrue、assertFailsWith并桥接到 JUnit 5junit-jupiter-engine:5.10.0JUnit 5 测试引擎io.mockk:mockk:1.13.8MockK 库提供mockk()、coEvery、coVerify等协程友好的 mock APIkotlinx-coroutines-test:1.7.3提供runTest、TestScope、advanceUntilIdle等协程测试工具。tasks.test中通过exclude(**/*IntegrationTest*)让默认test任务跳过集成测试而注册的integrationTest任务通过include(**/*IntegrationTest*)只运行集成测试。这种按文件命名约定 include/exclude 过滤的模式让两类测试互不干扰开发者日常跑./gradlew test不会触发真实 AWS 调用。仓库中真实服务的 Gradle 配置文档模板是规范基线仓库中实际服务的构建文件在此基础上有所演进。以 kotlin/services/sqs/build.gradle.kts 为例Kotlin 插件版本已升级为kotlin(jvm) version 2.1.0通过implementation(platform(aws.sdk.kotlin:bom:1.5.63))引入 AWS SDK for Kotlin BOM 统一管理各服务 SDK 版本再以implementation(aws.sdk.kotlin:sqs)声明具体服务避免手工维护版本号测试依赖使用testImplementation(org.junit.jupiter:junit-jupiter:5.9.2)聚合坐标等价于 engine api额外引入aws.smithy.kotlin:http-client-engine-okhttp与http-client-engine-crt两个 HTTP 客户端引擎供真实客户端发起请求tasks.test中配置useJUnitPlatform()、testLogging { events(passed, skipped, failed) }并通过testClassesDirs files(build/classes/kotlin/test)与classpath files(build/classes/kotlin/main, build/resources/main)显式补全测试类路径。kotlin/services/apigateway/build.gradle.kts 与 sqs 的配置结构一致并额外引入了jackson-databind、gson、slf4j等 JSON 解析与日志依赖用于从 AWS Secrets Manager 读取测试参数并序列化。这说明仓库在文档模板之上还沉淀了一套Secrets Manager 存放测试参数 Gson 反序列化 SLF4J 日志的测试基础设施。单元测试模式MockK 驱动文档给出的单元测试范式以Tag(unit)标注在BeforeEach中通过mockk()创建 AWS SDK 客户端 mock再针对 Action 方法逐条验证成功路径、服务异常与通用异常。成功路径与 mock 交互验证Tag(unit) class {Service}ActionsTest { private lateinit var mockClient: {Service}Client private lateinit var {service}Actions: {Service}Actions BeforeEach fun setUp() { mockClient mockk() {service}Actions {Service}Actions() } Test fun test {actionName} success() runTest { // Arrange val testParam test-value val expectedResponse {ActionName}Response { {responseField} response-value } coEvery { mockClient.{actionName}(any{ActionName}Request()) } returns expectedResponse // Act val result {service}Actions.{actionName}(mockClient, testParam) // Assert assertNotNull(result) assertEquals(response-value, result.{responseField}) coVerify { mockClient.{actionName}(any{ActionName}Request()) } } ... }该模式的关键点runTest包裹测试体AWS SDK for Kotlin 的所有 API 均为 suspend 函数必须在runTest来自kotlinx-coroutines-test提供的协程作用域中调用coEvery/coVerifyMockK 针对挂起函数的专用 DSLcoEvery用于配置 suspend 函数的返回值coVerify用于断言调用确实发生any{ActionName}Request()通配匹配请求参数不校验具体请求内容assertNotNullassertEquals验证返回值非空且关键字段与期望一致Arrange / Act / Assert 三段式注释明确测试结构便于维护。错误条件覆盖ParameterizedTest 参数化服务异常文档要求覆盖规范中的全部错误条件并推荐用 JUnit 5 参数化测试批量验证多个服务异常码ParameterizedTest ValueSource(strings [BadRequestException, InternalServerErrorException, ResourceNotFoundException]) fun test {actionName} service exception(errorCode: String) runTest { // Arrange val testParam test-value val serviceException {Service}Exception.builder { message Test error message }.build() coEvery { mockClient.{actionName}(any{ActionName}Request()) } throws serviceException // Act Assert assertFailsWith{Service}Exception { {service}Actions.{actionName}(mockClient, testParam) } coVerify { mockClient.{actionName}(any{ActionName}Request()) } }ParameterizedTestValueSource(strings [...])同一个测试方法按多个输入各执行一次{Service}Exception.builder { message ... }.build()通过 AWS SDK 模型的 Builder 构造服务异常assertFailsWith{Service}Exception断言调用抛出指定类型的异常每个参数化用例结束后同样coVerify确保异常路径确实触发了客户端调用。通用异常测试除服务异常外还需验证通用运行时异常如网络抖动、超时等底层错误也能正确传播Test fun test {actionName} general exception() runTest { // Arrange val testParam test-value val exception RuntimeException(General error) coEvery { mockClient.{actionName}(any{ActionName}Request()) } throws exception // Act Assert assertFailsWithRuntimeException { {service}Actions.{actionName}(mockClient, testParam) } coVerify { mockClient.{actionName}(any{ActionName}Request()) } }分页逻辑测试基于请求内容的条件 mock对于list类带分页nextToken的操作文档给出了仓库中最具参考价值的测试模式——利用match按请求内容返回不同页数据从而在不真实调用 AWS 的前提下完整验证分页聚合逻辑Test fun test list{Resources} with pagination() runTest { // Arrange val page1Response List{Resources}Response { {resources} listOf( {Resource} { {resourceId} resource-1 {resourceName} test-resource-1 }, {Resource} { {resourceId} resource-2 {resourceName} test-resource-2 } ) nextToken token-1 } val page2Response List{Resources}Response { {resources} listOf( {Resource} { {resourceId} resource-3 {resourceName} test-resource-3 } ) nextToken null } coEvery { mockClient.list{Resources}(matchList{Resources}Request { it.nextToken null }) } returns page1Response coEvery { mockClient.list{Resources}(matchList{Resources}Request { it.nextToken token-1 }) } returns page2Response // Act val result {service}Actions.list{Resources}(mockClient) // Assert assertEquals(3, result.size) assertEquals(resource-1, result[0].{resourceId}) assertEquals(resource-2, result[1].{resourceId}) assertEquals(resource-3, result[2].{resourceId}) coVerify(exactly 2) { mockClient.list{Resources}(anyList{Resources}Request()) } }要点解析matchList{Resources}Request { it.nextToken null }按请求体中的nextToken条件精确匹配第一次请求无 token第二次请求携带token-1coEvery按相同方式匹配并返回第二页assertEquals(3, result.size)验证 Action 内部确实把两页数据聚合并集coVerify(exactly 2)严格断言分页循环恰好发起两次调用防止实现退化如只取一页或死循环。这一模式在仓库中同样可以找到思想映射真实服务测试如 kotlin/services/s3/src/test/kotlin/com/kotlin/s3/PresignTests.kt也遵循先 Arrange 环境、再 Act、finally 清理的顺序只不过真实集成场景用真实客户端单元场景用 mock 客户端。完整 AWS 数据结构杜绝精简字段文档用专门的CRITICAL章节强调mock 返回的 AWS 响应数据必须完整否则会因 SDK 模型校验如必需字段缺失、ARN 格式非法、时间戳字段缺失导致测试失败或行为失真。// ❌ WRONG - Minimal data that fails validation val resources listOf( {Resource} { {resourceId} resource-1 } ) // ✅ CORRECT - Complete AWS data structure val resources listOf( {Resource} { {resourceId} resource-1 {resourceName} test-resource {resourceArn} arn:aws:service:region:account:resource/resource-1 {resourceStatus} {ResourceStatus}.Active {createdAt} aws.smithy.kotlin.runtime.time.Instant.now() {updatedAt} aws.smithy.kotlin.runtime.time.Instant.now() {tags} mapOf(Environment to Test) } )正确范式应补齐的字段类型包括标识类字段{resourceId}、{resourceName}ARN 字段{resourceArn}需符合arn:aws:service:region:account:resource/{id}格式状态枚举{resourceStatus}使用模型枚举值如{ResourceStatus}.Active时间戳字段{createdAt}/{updatedAt}使用aws.smithy.kotlin.runtime.time.Instant.now()AWS SDK for Kotlin 的时间类型而非java.time标签字段{tags}使用mapOf(...)。从源码层面看仓库中集成测试大量使用了完整结构。例如 kotlin/services/s3/src/test/kotlin/com/kotlin/s3/PresignTests.kt 中通过aws.smithy.kotlin.runtime.time.Instant与java.time.temporal.ChronoUnit构造签名有效期kotlin/services/sqs/src/test/kotlin/SQSTest.kt 中则从 Secrets Manager 读取队列名、消息内容等完整参数。可以推断规范强调完整数据的深层原因是避免 mock 返回残缺对象掩盖 Action 代码中对次要字段的访问逻辑。集成测试模式真实客户端与资源生命周期集成测试使用Tag(integration)标注通过真实 AWS 客户端{Service}Client { region us-east-1 }调用真实服务。文档模板将资源生命周期管理集中到companion object中Tag(integration) class {Service}IntegrationTest { companion object { private lateinit var {service}Client: {Service}Client private lateinit var {service}Actions: {Service}Actions private var testResourceId: String? null BeforeAll JvmStatic fun setUp() { {service}Client {Service}Client { region us-east-1 } {service}Actions {Service}Actions() } AfterAll JvmStatic fun tearDown() runTest { // Clean up test resources testResourceId?.let { resourceId - try { {service}Actions.deleteResource({service}Client, resourceId) } catch (e: Exception) { // Ignore cleanup errors } } {service}Client.close() } } Test fun test resource lifecycle() runTest { try { // Create resource testResourceId {service}Actions.createResource({service}Client, test-resource) assertNotNull(testResourceId) // Get resource val resource {service}Actions.getResource({service}Client, testResourceId!!) assertNotNull(resource) assertEquals(testResourceId, resource.{resourceId}) // List resources (should include our test resource) val resources {service}Actions.listResources({service}Client) assertTrue(resources.any { it.{resourceId} testResourceId }) } catch (e: Exception) { throw AssertionError(Integration test failed: ${e.message}, e) } } Test fun test service connectivity() runTest { // Test basic service connectivity val resources {service}Actions.listResources({service}Client) assertNotNull(resources) } }该模式的工程要点BeforeAll/AfterAllJvmStatic类级别一次性初始化和收尾由于tearDown需要调用 suspend 清理函数用runTest包裹清理逻辑兜底try { ... } catch (e: Exception) { /* Ignore cleanup errors */ }——清理失败不阻断测试结果但必须尝试清理避免资源泄漏{service}Client.close()显式关闭客户端释放连接生命周期测试按 Create → Get → List 的顺序验证资源能被创建、读取、并出现在列表结果中这是对create, read, delete闭环中前半段的验证连通性测试单独验证客户端到服务的连通性帮助快速区分环境问题与代码问题。文档的Test Categories章节进一步界定了集成测试的职责使用真实 AWS 客户端与服务、端到端测试完整工作流、需要 AWS 凭证与权限、必须包含清理逻辑以避免资源泄漏。运行这类测试会产生真实 AWS 调用与潜在费用这也正是 Gradle 配置中将其从默认test任务排除的原因。场景测试模式mock 用户输入与输出捕获场景测试用于验证面向控制台的示例程序如{Service}Basics的main函数在模拟用户输入下能否走通完整交互流程。文档给出的模式核心是用ByteArrayInputStream替换System.in、用ByteArrayOutputStream捕获System.outTag(integration) class {Service}ScenarioTest { private lateinit var {service}Client: {Service}Client private lateinit var outputStream: ByteArrayOutputStream private lateinit var originalOut: PrintStream BeforeEach fun setUp() { {service}Client {Service}Client { region us-east-1 } // Capture System.out for testing outputStream ByteArrayOutputStream() originalOut System.out System.setOut(PrintStream(outputStream)) } AfterEach fun tearDown() runTest { System.setOut(originalOut) {service}Client.close() } Test fun test scenario with mocked input() runTest { // Mock user inputs for automated testing val simulatedInput n\nn\ny\n // No existing resource, no details, yes cleanup System.setIn(ByteArrayInputStream(simulatedInput.toByteArray())) // Run scenario try { // Assuming main function exists in {Service}Basics or similar main(arrayOf(us-east-1)) } catch (e: Exception) { throw AssertionError(Scenario test failed: ${e.message}, e) } // Verify output contains expected messages val output outputStream.toString() assertTrue(output.contains(Welcome to the {AWS Service} basics scenario!)) assertTrue(output.contains(Setting up {AWS Service})) } Test fun test scenario with existing resources() runTest { // Create a test resource first var testResourceId: String? null try { val actions {Service}Actions() testResourceId actions.createResource({service}Client, test-resource) // Mock user inputs to use existing resource val simulatedInput y\nn\ny\n // Yes existing, no details, yes cleanup System.setIn(ByteArrayInputStream(simulatedInput.toByteArray())) // Run scenario main(arrayOf(us-east-1)) val output outputStream.toString() assertTrue(output.contains(Found)) assertTrue(output.contains(existing resource)) } finally { // Clean up test resource testResourceId?.let { resourceId - try { {Service}Actions().deleteResource({service}Client, resourceId) } catch (e: Exception) { // Ignore cleanup errors } } } } }要点解析模拟输入串约定n\nn\ny\n中的每个\n对应一次readln()回车按顺序表示对交互提示的回答如是否使用已有资源否 / 是否查看详情否 / 是否清理是测试代码需依据场景实际提问顺序精心设计输入串System.setIn/System.setOut切换运行前注入模拟流tearDown中必须恢复原始System.outSystem.setOut(originalOut)否则会影响同 JVM 中其他测试的输出与日志输出断言通过outputStream.toString()检查控制台是否包含预期的关键提示文案验证用户交互路径是否完整双路径覆盖分别测试新建资源路径与已有资源路径y开头覆盖场景的分支逻辑清理的确定性使用try/finally而非try/catch确保资源无论如何都被删除且清理异常被吞掉。测试执行命令文档提供了四类 Gradle 执行命令覆盖只跑单元 / 只跑集成 / 全量 / 指定类四种诉求# Unit Tests Only cd kotlin/services/{service} ./gradlew test --exclude-task integrationTest # Integration Tests Only cd kotlin/services/{service} ./gradlew integrationTest # All Tests cd kotlin/services/{service} ./gradlew test integrationTest # Specific Test Class ./gradlew test --tests {Service}ActionsTest结合 kotlin/README.md 的说明这些测试也可以直接从 IDE如 IntelliJ IDEA运行每项测试通过后会打印如Test 3 passed的日志。仓库还提示运行 JUnit 测试前必须在resources目录下的config.properties或通过 Secrets Manager中定义测试所需的值未定义全部值会导致测试失败——这一要求与仓库中大量测试通过 kotlin/services/dynamodb/src/test/kotlin/DynamoDB.kt、kotlin/services/apigateway/src/test/kotlin/APIGatewayTest.kt 等方式从 AWS Secrets Manager 读取测试参数的做法相印证。Coroutines Testingsuspend 函数与协程作用域测试由于 AWS SDK for Kotlin 的 API 全部为 suspend 函数协程测试是整套测试体系的地基。文档给出两种核心用法使用 runTest 测试 suspend 函数Test fun test suspend function() runTest { // Test suspend functions here val result suspendingFunction() assertNotNull(result) }runTest来自kotlinx-coroutines-test它创建受控的测试调度器测试体内的虚拟时间可以即时推进无需真实等待网络与延时。所有 suspend 测试无论单元、集成还是场景都必须包在runTest中否则挂起调用无法执行完毕。测试自定义 Coroutine ScopeTest fun test with custom scope() runTest { val testScope TestScope() testScope.launch { // Test coroutine operations } testScope.advanceUntilIdle() }TestScope配合advanceUntilIdle()可让测试主动推进调度器直到所有待执行协程完成适用于验证后台作用域中启动的并发操作。仓库现有测试在协程使用上的实际形态值得说明多数真实测试文件如 kotlin/services/apigateway/src/test/kotlin/APIGatewayTest.kt、kotlin/services/sqs/src/test/kotlin/SQSTest.kt目前使用runBlocking包裹测试体并配合TestInstance(TestInstance.Lifecycle.PER_CLASS)与TestMethodOrder(OrderAnnotation::class)实现有状态的顺序测试而 kotlin/services/s3/src/test/kotlin/com/kotlin/s3/PresignTests.kt 采用BeforeEach/AfterEachrunBlocking的按用例隔离风格。可以推断文档推荐的runTest是对既有实践的演进方向runTest比runBlocking提供虚拟时钟能更快、更确定地测试含延时、重试或分页循环的 suspend 逻辑。Kotlin 特有的测试特性协程异常测试Test fun test coroutine exception() runTest { assertFailsWithServiceException { suspendFunctionThatThrows() } }在runTest作用域内用assertFailsWithServiceException断言挂起函数抛出的服务异常与单元测试模式中的错误条件覆盖互为补充。扩展函数测试Test fun test extension function() { val resources listOf(/* test data */) val filtered resources.filterActive() assertEquals(expectedCount, filtered.size) }纯逻辑的扩展函数如过滤、映射等无 I/O 操作无需协程与 mock直接作为普通 JUnit 测试即可这也是整套测试体系中唯一不需要runTest的场景。测试要求清单与分类总结测试要求 Checklist文档给出的完整验收清单如下✅JUnit 5 annotationsTest、BeforeEach、AfterEach✅MockK for unit testsmockk()、coEvery、coVerify✅Coroutines testingrunTest、TestScope✅Complete AWS data structuresin all tests✅Proper test tagsTag(integration)✅Error condition coverageper specification✅Integration test cleanuptry/finallyblocks✅Region specificationus-east-1✅Resource lifecycle testingcreate, read, delete✅Parameterized testsfor multiple error conditions三类测试的职责边界测试类别客户端典型内容特点Unit TestsMockK mock单个 suspend 函数的成功/失败路径无真实 AWS 调用执行快Integration Tests真实客户端完整工作流端到端验证需要 AWS 凭证与权限必须清理资源Scenario Tests真实客户端 mock 用户输入完整场景与用户交互路径归类为 integration需真实 AWS具体而言单元测试逐个隔离验证 suspend 函数并覆盖成功与错误分支集成测试验证端到端完整工作流并在结束后清理资源场景测试以模拟用户输入驱动示例程序、校验控制台输出与多用户路径已有资源 / 新建资源且由于使用真实客户端被归入 integration 测试类别。常见测试失败点与规避策略文档列出九项高频失败原因逐一说明规避方式❌mock 中使用不完整的 AWS 数据结构补齐 ARN、状态枚举、时间戳、标签等字段见上文完整 AWS 数据结构一节❌集成测试缺少测试标签集成/场景测试必须标注Tag(integration)否则会混入默认test任务在无凭证环境误跑❌集成测试未处理清理使用try/finally或AfterAll兜底删除资源防止资源泄漏与账单浪费❌忘记为测试客户端设置 AWS Region客户端必须显式指定region规范统一为us-east-1否则默认区域解析可能失败❌未覆盖规范中的全部错误条件结合ParameterizedTestValueSource批量覆盖服务异常与通用异常❌场景测试未 mock 用户输入必须用System.setIn(ByteArrayInputStream(...))注入输入流才能无人工干预地自动化运行❌缺少 Gradle 测试配置useJUnitPlatform()、exclude/include IntegrationTest*与integrationTest任务缺一不可❌suspend 函数测试未使用 runTest挂起调用无法在普通Test方法内执行完成❌MockK 用法错误coEvery vs every对 suspend 函数必须使用协程专用变体coEvery/coVerify/coAnswer普通every无法拦截挂起调用。总结把测试规范落到仓库实践本文档steering_docs/kotlin-tech/tests.md为 AWS SDK for Kotlin 示例代码提供了从生成前知识库查询到三类测试模式再到Gradle 任务隔离与执行命令的完整测试工程规范。在仓库中可以直接对照的落地样例包括构建配置kotlin/services/sqs/build.gradle.kts 与 kotlin/services/apigateway/build.gradle.kts 展示了 BOM 版本管理、JUnit 5 引擎与测试任务配置的实际形态集成测试范例kotlin/services/apigateway/src/test/kotlin/APIGatewayTest.ktTestInstance(PER_CLASS)TestMethodOrder Secrets Manager 取参、kotlin/services/sqs/src/test/kotlin/SQSTest.kt队列生命周期、kotlin/services/dynamodb/src/test/kotlin/DynamoDB.kt表与 PartiQL 场景按用例隔离的范式kotlin/services/s3/src/test/kotlin/com/kotlin/s3/PresignTests.ktBeforeEach创建随机桶 AfterEach清理 断言签名内容一致运行说明kotlin/README.mdIDE 或命令行运行、config.properties/Secrets Manager 测试参数要求。按照本文档生成测试套件时建议的落地顺序是先在build.gradle.kts配齐 JUnit 5 / MockK / kotlinx-coroutines-test 依赖与integrationTest任务隔离再按{Service}ActionsTest单元MockK 完整数据结构 参数化错误覆盖→{Service}IntegrationTest真实客户端 生命周期 清理→{Service}ScenarioTestmock 输入 输出断言逐层补齐最后用文档给出的四组 Gradle 命令分别验证单元与集成测试。这样既能保证示例代码的快速回归又能守住不泄漏资源、不误跑真实服务的工程底线。赞分享示例工程教程后端【免费下载链接】aws-doc-sdk-examplesWelcome to the AWS Code Examples Repository. This repo contains code examples used in the AWS documentation, AWS SDK Developer Guides, and more. For more information, see the Readme.md file below.项目地址https://gitcode.com/gh_mirrors/aw/aws-doc-sdk-examples点击查看免费下载相关推荐AWS Migration Hub Java 示例代码实战基于 AWS SDK for Java 2.x 的配置、API 演示与 JUnit 5 集成测试AWS Migration Hub Java 示例代码实战基于 AWS SDK for Java 2.x 的配置、API 演示与 JUnit 5 集成测试 本示例工程教程后端基于 AWS SDK for Java 2.x 的 Amazon API Gateway 实战指南代码示例运行与 JUnit 集成测试基于 AWS SDK for Java 2.x 的 Amazon API Gateway 实战指南代码示例运行与 JUnit 集成测试 本文以 AWS Cod示例工程教程后端基于 AWS SDK for Java 2.x 的 Amazon GuardDuty 示例源码解析、运行与 JUnit 集成测试指南基于 AWS SDK for Java 2.x 的 Amazon GuardDuty 示例源码解析、运行与 JUnit 集成测试指南 本文以 aws doc示例工程教程后端上一篇MySQLTuner 分阶段执行耗时追踪--verbose 时序输出机制与实现解析下一篇AI 工程师必读全面理解 LLM 中的 Context上下文与上下文工程实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考