feature: dyld && LD 链接器

Chapter1 - iOS/1.75.md

@@ -1075,6 +1075,19 @@ QA：一个被测方法，有诸多 case，为什么不写在一个测试方法
 
 
 
+### 15. Swift 测试用例代码测试 OC 被测代码
+
+编写 Swift 测试代码去测试 OC 被测类的时候，需要做一些处理：
+
+1. 主工程不管是不是混编，但为了让 Swift 测试代码，可以访问到 OC 被测类，需要创建一个 Swift 文件，系统会自动创建 bridge 文件，且需要在 `AppTestingExplore-Bridging-Header.h` 文件中导出需要被测的头文件
+2. 在 Swift 测试文件中，导入主工程 module。 
+
+<img src="./../assets/SwiftTestingForOCClass.png" style="zoom:30%; align:left;">
+
+
+
+`@testable` 是 Swift 语言的一个特性，它允许测试用例访问应用程序或框架中标记为 `internal` 或 `private` 的属性、方法和其他成员。这样做可以在不改变访问级别的情况下编写测试用例，从而保持代码的封装性和安全性。使用 `@testable` 可以增强测试覆盖率，因为它允许测试那些通常因为访问级别限制而无法测试的内部实现细节。同时，它还有助于保持代码的封装性，因为不需要将内部实现细节暴露为 `public` 就可以进行单元测试。此外，`@testable` 提高了测试的灵活性，在不修改代码访问级别的情况下，能够对代码进行全面的测试
+
 
 
 ## 四、网络测试
@@ -1164,6 +1177,8 @@ SPEC_END
 
 ## 五、UI 测试
 
+### 基础使用
+
 上面文章大篇幅的讲了单元测试相关的话题，单元测试十分适合代码质量、逻辑、网络等内容的测试，但是针对最终产物 App 来说单元测试就不太适合了，如果测试 UI 界面的正确性、功能是否正确显然就不太适合了。Apple 在 Xcode 7 开始推出的 `UI Testing`  就是苹果自己的 UI 测试框架。
 
 很多 UI 自动化测试框架的底层实现都依赖于 `Accessibility`，也就是 App 可用性。`UI Accessibility` 是 iOS 3.0 引入的一个人性化功能，帮助身体不便的人士方便使用 App。
@@ -1298,6 +1313,44 @@ Accessibility 通过对 UI 元素进行分类和标记。分类成类似按钮
 
 
 
+### 经验心得
+
+UI 测试另一个问题是，某些 UI 方法比如 AppDelegate 里包含太多 SDK 的或者拉接口的场景，启动会比较慢，测试的诉求是：单个测试 case 需要快速运行。而 UI 测试聚焦的不是借口业务逻辑，所以期望 AppDelegate 里的拉接口这样的逻辑不要走，太慢影响测试速度。
+
+理论分析：如果可以从 `NSClassFromString(@"XCTestCase")` 方式获取到值，说明是测试环境，可以简化 AppDelegate 逻辑。
+
+具体做法是在开发阶段预留测试口子。非测试模式，走正常的业务逻辑；测试模式，走简化版 AppDelegate 逻辑。
+
+第一步：改造 `main.m`
+
+```objective-c
+int main(int argc, char * argv[]) {
+    NSString * appDelegateClassName;
+    @autoreleasepool {
+        // Setup code that might create autoreleased objects goes here.
+        id testClass = NSClassFromString(@"XCTestCase");
+        appDelegateClassName = testClass ? @"TestMockAppDelegate" : NSStringFromClass([AppDelegate class]);
+    }
+    return UIApplicationMain(argc, argv, nil, appDelegateClassName);
+}
+```
+
+第二步：创建 mock 的简化版 `TestMockAppDelegate`，可以剔除一些 UI 测试不关心的逻辑。甚至只需要完成这个方法基础实现都可以。
+
+
+
+### 探索
+
+开发的单元测试代码，运行的背后也是一个可执行文件。查看内部，可以发现一堆和测试相关的 framework。
+
+<img src="./../assets/XcodeUnitTestDyanimcFramework.png" style="zoom:30%"  />
+
+思考：一个工程中，只要写好了测试代码，是不是加载这几个动态库就可以运行测试用例了？
+
+
+
+
+
 ## 六、精准测试
 
 精准测试是最近很火的一个概念，但是也不算在概念阶段，很多公司都落地并实施了精准测试。单测是开发者为了方法级别写的测试用例。精准测试是代码级别的测试覆盖。
@@ -1316,10 +1369,12 @@ Accessibility 通过对 UI 元素进行分类和标记。分类成类似按钮
 
 下面是之前在有赞，开发完精准测试系统后，落地到一个业务项目中取得的价值，帮助2位 QA 发现漏测的代码，倒逼 QA 去设计更完善的测试 case、分析覆盖率低是开发者的兜底代码太多还是真的漏掉了业务 case。
 
-<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/iOS_PreciousUnitTest1.png" style="zoom:20%;display:inline">                     <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/iOS_PreciousUnitTest2.png" style="zoom:20%;display:inline">
+<img src="./../assets/iOS_PreciousUnitTest1.png" style="zoom:20%;display:inline">                     <img src="./../assets/iOS_PreciousUnitTest2.png" style="zoom:20%;display:inline">
 
 精准测试助力业务，质量更加稳定。
 
+精准测试怎么实现？核心问题是 iOS 侧开发语言有 OC、Swift，分别对应不同的编译器：clang、swiftc，插桩手段不一样。具体实现原理和细节可以看这篇文章：[精准测试最佳实践](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.108.md)
+
 
 
 ## 七、 测试经验总结