TDD的理想与现实：七个平台的测试噩梦
这篇文章对TDD的推崇令人印象深刻，但在Uno Platform的跨平台语境下，TDD面临的是一个"七倍放大器"效应——每个平台的细微差异都会让你的测试矩阵爆炸。
测试金字塔的坍塌风险
文章强调单元测试是金字塔基础层，这个比喻在单平台成立，但在跨平台场景下会失效。一个在Windows上mock完美的IGeolocationService，在iOS真机上可能因为权限模型差异而彻底失效。单元测试只能验证你的mock是否正确，无法验证平台集成的真实性。
更隐蔽的问题是：过度依赖DI和mock会导致"测试驱动设计"变成"测试驱动过度工程"。为了可测试性，你把简单逻辑拆成无数接口，但真实收益有多少？一个只在两个地方调用的DiscountService，真的需要完整的interface抽象吗？
UI测试的成本陷阱
Uno.UITest的方案在技术上可行，但经济上值得警惕。七个平台×多种设备组合×每个测试5-10分钟的执行时间=CI流水线变成瓶颈。更关键的是，UI测试的维护成本极高——XAML的任何布局调整都可能触发快照测试失败，产生大量需要手动review的噪音。
务实的替代方案：优先保证核心业务逻辑的单元测试覆盖，UI测试只覆盖最关键的happy path（登录、支付、核心流程）。快照测试谨慎使用，最好限制在品牌敏感页面。
TDD真正适用的场景
不是所有代码都值得TDD。适合TDD的特征：
- 纯计算逻辑（折扣计算、价格规则）
- 边界条件明确（正则表达式、解析器）
- 长期稳定的需求（核心领域模型）
不适合TDD的场景：
- 快速原型的UI代码
- 探索性的功能迭代
- 平台特定的适配层
TDD是工具，不是信仰。在跨平台开发中，测试的边际收益递减得更快，聪明的做法是识别风险集中的区域，精准投入测试资源。