写了一个测试类，按 Cmd+R 跑 App 一切正常，转头打开测试面板，里面空空如也。不是测试写错了，是 Scheme 里没勾测试 target。这个坑我第一次也踩过。
测试这块常见的卡点就几个：面板里找不到测试、单条测试点了没反应、真机上 UI 测试卡住。这篇用 KXApp 把 iOS 单元测试这条线走一遍，XCTest 和 Swift Testing 分别怎么被列出来，单条和整个类怎么运行，模拟器和真机有什么区别，失败了又该去哪一行看。
测试为什么没出现在面板里？
VS Code 活动栏里那个烧杯图标就是测试资源管理器。打开 iOS 工程，测试会按 target › 类 › 方法分组列出来，XCTest 的类和用例、Swift Testing 的 @Test 函数都在里面。
如果面板是空的，先别怀疑插件。去 Xcode 的 Scheme 编辑器里看一眼 Test 那一栏，测试 target 有没有勾上。没勾，测试压根不会进入运行计划，面板自然也不会列。新建或者复制 Scheme 之后，测试 target 未必会跟着带过来，得手动确认一遍。说实话，这一步很容易被忽略。
这个前提得记牢：测试用哪个 Scheme，那个 Scheme 就必须带测试动作。换 Scheme 之后发现测试没了，多半是新的 Scheme 没配测试 target。
测试面板认的是 Scheme 里的测试动作，不是测试文件放在哪个目录。 文件写好了、target 也建了，Scheme 没勾，还是跑不起来。
XCTest 和 Swift Testing 怎么被列出？
其实两种框架都在同一个面板里。XCTest 按类和方法列，Swift Testing 的 @Test 函数也会出现，带显示名的用例显示的是你写的名字，不是函数名，列表里看到的是那句人话，找起来比函数名直观。
列表里每个测试方法旁边有运行按钮，点一下就跑这一条。这个方法适合写测试的时候用：写一条、跑一条、看结果，不用每次都把整个 target 拉起来。
有个细节挺省事：测试方法旁边的行号区也能点运行，不用先切到测试面板再找。写代码和跑测试在同一个编辑器里，来回切窗口的次数少了很多。
单条、整个类、整个 target 怎么跑？
KXApp 把测试入口放在 VS Code 的测试资源管理器里，运行粒度分三档：单个方法、整个类、整个 target。点哪一档，就只跑哪一档，不会顺手把旁边的测试也带进去嘛。一个类里哪条挂了，面板会直接标出来，不用自己数。
跑测试用的是当前运行目标。状态栏或者 Xcode 工程视图里选的是模拟器，测试就在模拟器里跑；选的是连着 iPhone，就在真机上跑。运行过程中，每个用例会实时显示开始、通过或失败，不用等全部跑完才知道结果。
我自己的习惯是：改完一个方法，先跑这一条；这一条过了，再跑整个类；提交前把整个 target 跑一遍。先跑一条，再跑一类，别一上来就全量。 全量跑一次要等一会儿，中间错一条，前面的结果也白等了。
模拟器和真机，测试在哪边跑？
测试跟着当前运行目标走。模拟器启动快，适合日常写测试；真机更接近实际环境，涉及性能、权限、硬件能力的用例，还是得在真机上过一遍。相机、推送、生物识别这些，模拟器给不了真实结果。
UI 测试也在同一个面板里，真机上同样能跑。第一次在真机上跑之前，手机要解锁、信任这台 Mac、打开开发者模式，还要让 Xcode 准备过这台设备。没准备过的设备，第一次启动会慢很多（别问我怎么知道的），等 Xcode 的 Devices and Simulators 跑完一次，后面就正常了。
切换运行目标不用改测试代码，状态栏里换一台设备就行呢。换完之后重新点运行，测试会在新的目标上再跑一遍。
失败在哪一行看？
失败的用例会标在出错的那一行，旁边带上断言消息。点一下就能跳到对应的代码，不用在输出里翻半天，省得折腾。断言消息写得具体一点，失败时能少翻一次代码。
测试面板里展示的是用例结果，App 自己的 print、NSLog 输出在「输出 › kxapp Console」里。两边的信息别混着看：断言失败看测试面板的行标记，App 运行时的问题看 Console。
如果一条测试一直通过，但你怀疑它根本没执行，先看面板里的运行状态，再看 Scheme 的测试动作。测试被跳过的时候，面板有时候不会给出很明显的提示，得自己确认一遍。
UI 测试有什么额外条件？
UI 测试和单元测试在同一个面板里列出，运行方式也一样。区别在于它会真的把 App 拉起来，在界面上点按、输入、断言，跑一条比单元测试慢不少。
条件还是那几个：测试 target 要进 Scheme 的测试动作，运行目标要能装 App，真机要解锁并信任。UI 测试跑失败的时候，先区分是断言不通过，还是 App 根本没启动起来------后一种去看 kxapp Console，多半能找到启动失败的原因。
和 Xcode Test Navigator、xcodebuild test 的分工
Xcode 的 Test Navigator 排布和 VS Code 这边很像，测试动作、Scheme、测试计划这些配置还是得在 Xcode 里做。用它跑测试也很顺，尤其是你本来就开着 Xcode 的时候，大概顺手就跑了。覆盖率这些配置，还是在 Xcode 里看更全。
xcodebuild test 适合无人值守的场景：CI 里跑全量测试、生成结果、失败就断构建。它不需要编辑器，也不需要人盯着，和 VS Code 里的交互式运行是两回事。
KXApp 站的是编辑器这一侧：写代码和跑测试在同一个窗口里，当前运行目标切一下就能换设备，单条测试点一下就跑。它不替代 CI，也不负责测试计划的管理；日常开发里的红绿循环，用它比较顺手。顺便说一句，插件免费、不用注册，也不上传代码，这点对不想把工程交给外部服务的团队还挺重要。
先把一条测试跑顺
顺序可以这么来：先在 Xcode 里确认 Scheme 带了测试动作，回到 VS Code 打开测试面板，找一条最简单的用例跑通；再跑整个类，切到真机上跑一遍；UI 测试留到后面，等单元测试稳定了再上。第一次跑测试别急着上 UI 测试，单元测试跑顺了，UI 测试的失败才好判断是界面问题还是环境问题。
iOS 单元测试这件事，工具只是把入口搬到 VS Code 里，测试本身还是得写。反正测试这东西，跑起来才有意义，先把一条跑顺，再谈覆盖率和 CI 吧。