移动开发认证鉴权社交数据分析【免费下载链接】facebook-ios-sdkUsed to integrate the Facebook Platform with your iOS tvOS apps.项目地址https://gitcode.com/gh_mirrors/fa/facebook-ios-sdk点击查看免费下载本篇指南以 facebook-ios-sdk 仓库的 .llms/skills/testing.md 测试规范文档为骨架结合仓库内真实测试代码与共享测试基建TestTools系统讲解该 SDK 的 Swift 单元测试编写约定包括final测试类声明、隐式解包可选的使用、setUp()依赖注入、Test Double 命名、Sample*样例数据工厂以及基于captured*属性的交互断言模式。读完本篇你将能够按照 facebook-ios-sdk 的官方测试约定为任意模块编写风格统一、可维护、可复用的单元测试。规范适用范围这份 Testing Conventions 约束什么.llms/skills/testing.md的开头以 YAML front matter 声明了这份规范的两个关键属性--- oncalls: [sdk] apply_to_path: .*Tests.*\.swift ---oncalls: [sdk]该规范由 SDK 主工程facebook-ios-sdk 本体的测试代码遵循apply_to_path: .*Tests.*\.swift规范作用于所有路径中含Tests的 Swift 测试文件即各模块的XxxTests/目录下的测试源码。这意味着无论你是在FBSDKCoreKit/FBSDKCoreKitTests/、FBSDKLoginKit/FBSDKLoginKitTests/、FBSDKGamingServicesKit/FBSDKGamingServicesKitTests/还是FBAEMKit/FBAEMKitTests/中编写测试都需要遵守同一套约定。下文所有规则均以仓库中真实存在的测试文件作为证据。测试类声明一律使用final class继承 XCTestCase规范第一条要求所有测试类必须声明为final。这在全仓库的测试文件中被严格执行例如AuthenticationTokenFactoryTests.swiftfinal class AuthenticationTokenFactoryTests: XCTestCaseBackgroundRefreshManagerTests.swiftfinal class BackgroundRefreshManagerTests: XCTestCaseDeviceLoginManagerResultTests.swiftfinal class DeviceLoginManagerResultTests: XCTestCasefinal声明除了阻止测试类被子类化、减少动态派发开销之外更重要的是强制测试类保持扁平结构——测试用例之间不通过继承共享状态每个测试类的依赖都通过setUp()显式构建见下文从而保证测试的隔离性与可预测性。隐式解包可选IUO配合 SwiftLint 豁免注释测试中需要在setUp()里创建的属性如各种 Test Double 和被测对象使用隐式解包可选Implicitly Unwrapped OptionalsIUO并必须用 swiftlint 的禁用/启用注释将其包裹// swiftlint:disable implicitly_unwrapped_optional var loginManager: LoginManager! var settings: TestSettings! // swiftlint:enable implicitly_unwrapped_optional原文档给出的代码片段在仓库中被大量复现例如 DeviceLoginManagerTests.swift// swiftlint:disable implicitly_unwrapped_optional var poller: TestDevicePoller! var delegate: TestDeviceLoginManagerDelegate! var graphRequestFactory: TestGraphRequestFactory! var settings: TestSettings! var internalUtility: TestInternalUtility! var errorFactory: TestErrorFactory! var manager: DeviceLoginManager! // swiftlint:enable implicitly_unwrapped_optional需要注意两点采用 IUO 而非普通可选是因为这些属性在setUp()中必然会被赋值测试方法中使用时可以免去连续解包manager?.xxx让断言代码更简洁SwiftLint 的implicitly_unwrapped_optional规则默认对生产代码中的 IUO 告警SDK 生产代码尽量避免 IUO测试代码则需要显式豁免——这正是该仓库用注释包裹的原因。仓库中 FBSDKCoreKitTests 目录下的 AccessTokenTests.swift、AppLinkNavigationTests.swift、GraphRequestConnectionTests.swift 等多个文件 均遵循此模式。setUp() 与依赖注入一切依赖显式构建规范的第三条是setUp()的职责约定setUp()必须创建全部测试替身Test Double并通过setDependencies()注入被测对象必须先调用super.setUp()。以 DeviceLoginManagerTests.swift 为例这是最标准的写法override func setUp() { super.setUp() poller TestDevicePoller() delegate TestDeviceLoginManagerDelegate() graphRequestFactory TestGraphRequestFactory() settings TestSettings() internalUtility TestInternalUtility() errorFactory TestErrorFactory() manager DeviceLoginManager( permissions: permissions, enableSmartLogin: false ) manager.setDependencies( .init( devicePoller: poller, errorFactory: errorFactory, graphRequestFactory: graphRequestFactory, internalUtility: internalUtility, settings: settings ) ) manager.redirectURL redirectURL manager.delegate delegate manager.codeInfo sampleCodeInfo() }从源码结构看DeviceLoginManager这类 SDK 类通过setDependencies()接收一组依赖如网络请求工厂graphRequestFactory、轮询器devicePoller、设置对象settings等这属于依赖注入Dependency Injection设计。对应地测试代码可以注入 Test Double精确控制被测对象的外部依赖行为通过manager.getDependencies()断言注入的依赖是否被正确保留例如testCreatingWithDependencies用XCTAssertIdentical验证dependencies.graphRequestFactory graphRequestFactory见 DeviceLoginManagerTests.swift通过manager.resetDependencies()后断言回退到真实默认实现例如testDefaultDependencies验证默认的graphRequestFactory是具体类型GraphRequestFactory、默认settings是Settings.shared见 DeviceLoginManagerTests.swift。与之对称的是tearDown()仓库惯例会把所有属性置为nil后再调用super.tearDown()见 DeviceLoginManagerTests.swift避免测试实例间的状态残留。导入规范testable优先TestTools 承载共享替身规范要求被测模块使用testable import以便访问内部internalAPI共享测试替身来自TestTools模块使用普通import TestTools导入语句必须排序且testable导入排在最前。仓库中的实际导入写法与规范一致见 DeviceLoginManagerTests.swifttestable import FBSDKLoginKit import TestTools import XCTest而TestTools本身是一个独立的 Xcode target其工程配置定义在 TestTools/project.ymltarget 名TestTools源目录为TestTools/TestToolsBundle ID 为com.facebook.TestTools并生成 TestTools.xcodeproj。这样各模块的测试 target 都可以直接依赖TestTools复用同一套测试替身避免重复实现。Test Double 命名规范TestRealType规范第五条给出测试替身的命名模式模式TestRealType例如TestSettings、TestGraphRequestFactory它们要么位于各模块的ModuleTests/Helpers/目录模块私有要么位于共享的TestTools模块跨模块复用。仓库中的实例包括共享替身TestSettings.swift —— 实现SettingsProtocol与SettingsLogging覆盖 SDK 设置对象的全部可配置属性并带有logIfSDKSettingsChangedCallCount、recordInstallCallCount等调用计数属性用于断言模块替身TestDevicePoller.swift —— 实现DevicePolling协议用capturedInterval记录轮询间隔并直接同步执行传入的 block模块替身TestLoginProvider.swift —— 实现LoginProviding协议捕获登录配置、权限与回调。从源码结构看TestRealType替身的共同形态是遵循被测类型依赖的协议把协议方法实现为记录调用参数captured*或返回预设值从而让测试能够观察并控制被测对象的对外交互。Sample Data 工厂Sample*类型集中提供样例数据规范要求使用Sample*工厂类型来提供测试数据仓库中的典型实现包括SampleAccessTokens.swift提供defaultTokenString、defaultAppID、defaultUserID等常量以及validToken、expiredToken等预设AccessToken还有create(withRefreshDate:)、create(dataAccessExpirationDate:)等工厂方法用于快速构造带特定字段的 tokenSampleError.swift、SampleURLs.swift、SampleUserProfiles.swift 等同类工厂。Sample*工厂的价值在于测试数据集中管理、命名语义清晰、可组合复用。例如 DeviceLoginManagerResultTests.swift 中直接使用SampleAccessTokens.validToken构造登录结果而 DeviceLoginManagerTests.swift 则用SampleAccessTokens.validToken.tokenString等字段拼接 Graph API 的响应 JSON。交互断言用captured*属性验证调用规范第七条强调测试替身通过captured*属性记录与被测对象的每一次交互测试方法再对这些记录做断言。原文档给出的核心示例XCTAssertEqual(factory.capturedGraphPath, /me) XCTAssertTrue(delegate.capturedDidComplete)仓库中的实际断言案例DeviceLoginManagerTests.swiftXCTAssertEqual(delegate.capturedLoginManager, manager) // 委托收到回调 XCTAssertEqual(poller.capturedInterval, codeInfo.pollingInterval) // 轮询间隔被正确传递 let completion try XCTUnwrap(graphRequestFactory.capturedRequests.first?.capturedCompletionHandler) completion(nil, result, nil) // 手动触发 Graph 请求回调 let request try XCTUnwrap(graphRequestFactory.capturedRequests.last) XCTAssertEqual(request.tokenString, SampleAccessTokens.validToken.tokenString) XCTAssertEqual(request.graphPath, me)这种记录—触发—断言三步模式是该 SDK 测试的核心套路先执行被测方法使测试替身记录下参数或回调闭包从captured*中取出闭包并手动调用模拟异步完成如网络请求回包、轮询触发从而把异步流程变成同步可测用XCTAssertEqual/XCTAssertTrue/XCTAssertNil/XCTAssertNotNil等断言验证行为是否符合预期。配合XCTUnwrap解包可选值仓库中普遍使用断言失败时会给出清晰的可读错误信息。文件位置约定三层目录结构规范最后一条定义测试文件的位置内容路径模式模块专属测试Module/ModuleTests/模块专属测试替身Module/ModuleTests/Helpers/共享测试替身TestTools/TestTools/仓库中的实例完全吻合FBSDKLoginKit/FBSDKLoginKitTests/存放 LoginKit 的全部测试如 DeviceLoginManagerTests.swift、LoginManagerTests.swiftFBSDKLoginKit/FBSDKLoginKitTests/Helpers/存放模块级替身如 TestDevicePoller.swift、TestLoginProvider.swift、StubURLProtocol.swiftTestTools/TestTools/存放共享替身与样例数据如 TestSettings.swift、TestGraphRequest.swift、SampleAccessTokens.swift。划分逻辑很清晰跨模块都要用的替身下沉到 TestTools只有单个模块用的替身留在本模块的 Helpers 目录既避免共享模块过度膨胀又避免模块间重复造轮子。从约定到可运行测试如何组织与执行综合以上规范一个符合 facebook-ios-sdk 测试约定的测试文件骨架如下以某个登录模块测试为例testable import FBSDKLoginKit import TestTools import XCTest final class SomeManagerTests: XCTestCase { // swiftlint:disable implicitly_unwrapped_optional var settings: TestSettings! var graphRequestFactory: TestGraphRequestFactory! var manager: SomeManager! // swiftlint:enable implicitly_unwrapped_optional override func setUp() { super.setUp() settings TestSettings() graphRequestFactory TestGraphRequestFactory() manager SomeManager(settings: settings) manager.setDependencies(.init(graphRequestFactory: graphRequestFactory)) } override func tearDown() { manager nil graphRequestFactory nil settings nil super.tearDown() } func testFetchUsesExpectedGraphPath() { manager.fetch() XCTAssertEqual( graphRequestFactory.capturedGraphPath, /me, Should create a graph request with the expected graph path ) } }关于运行方式该仓库的测试 target 通过 XcodeGen 的project.yml声明各模块根目录下的 project.yml由仓库根目录的 generate-projects.sh 生成.xcodeproj共享的 TestTools 工程配置见 TestTools/project.yml。执行测试时可在 Xcode 中运行对应 scheme或参考 scripts/test.sh 与 scripts/run.sh 了解脚本化测试入口注意这些脚本面向本地 CI/Xcode 环境需在 macOS 与 Xcode 环境下运行。小结这套测试约定的设计意图把.llms/skills/testing.md的全部规则放在一起看facebook-ios-sdk 的测试约定围绕四个目标设计一致性final class、IUO 豁免注释、导入排序、TestRealType与Sample*命名让全仓库测试读起来像同一个作者写的隔离性所有依赖在setUp()中显式注入、在tearDown()中显式清理测试之间互不污染可观察性captured*属性把异步、隐式的对象交互显式记录下来配合手动触发回调将异步逻辑转化为确定性断言复用性模块私有的替身留在Helpers/通用替身与样例数据下沉到TestTools最大化共享、最小化重复。对于任何希望为 Facebook iOS SDK 贡献测试、或在自己的工程中借鉴这套测试工程实践的开发者来说这份规范配合仓库中的真实测试代码尤其是 DeviceLoginManagerTests.swift 这一完整范例就是一份可直接照抄的最佳实践模板。赞分享移动开发认证鉴权社交数据分析【免费下载链接】facebook-ios-sdkUsed to integrate the Facebook Platform with your iOS tvOS apps.项目地址https://gitcode.com/gh_mirrors/fa/facebook-ios-sdk点击查看免费下载相关推荐aws-doc-sdk-examples Go 测试规范基于 testtools 的 AWS SDK for Go v2 单元测试与集成测试实战指南aws doc sdk examples Go 测试规范基于 testtools 的 AWS SDK for Go v2 单元测试与集成测试实战指南 本文是示例工程教程后端Agent-Native进度跟踪监控智能体任务的完整方案Agent Native进度跟踪监控智能体任务的完整方案 Agent Native是一个用于构建智能体原生应用的框架提供了强大的进度跟踪功能帮助用户实时监人工智能AI AgentAgent 框架后端前端工具调用Facebook iOS SDK 单元测试覆盖率提升从 60% 到 90% 的终极实战指南Facebook iOS SDK 单元测试覆盖率提升从 60% 到 90% 的终极实战指南 想要让你的 Facebook iOS SDK 项目从平庸到卓越吗移动开发认证鉴权社交数据分析上一篇如何确保箭头绘制准确性Perfect Arrows 测试与调试终极指南下一篇算法与机器学习Learn-Algorithms中的梯度下降创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考