正如预期的那样，在使用视图层执行TDD(即首先编写测试(时，我通常会遇到困难。
也就是说，为了观察或触发某些可见的更改(布局或样式(，我需要公开视图的内部。这打破了封装，允许客户端代码做一些类似myView.label.text = "User"的事情。
为了避免这种情况，我要么在UIView类中添加getter方法：
var userName: String{ return label.text }
或者做一些只添加到测试框架中的扩展：
extension MyView{
//avoids making a getter just for the sake of testing, while keeping it private and interchangeable
var userName : String{
return (viewWithTag(someLabelTage) as! UILabel).text
}
另一种方法是跳过TDD工作流程(即在功能完成后手动测试(并添加快照测试(请参阅https://github.com/pointfreeco/swift-snapshot-testing)以增加覆盖范围，并在重构时拥有安全网。
考虑到这一切，我想知道是否还有其他模式或方法可以用来提高效率，同时保持对代码的信心。
不是Swift的专家，但不管语言/框架如何，有件事告诉我，你实际上让任务变得更难了。
在使用视图层执行TDD时，我通常会遇到困难
这是意料之中的事。View支持很简单，根本没有任何行为(即域逻辑(。它应该是简单的用户交互，并将数据绑定到视图中的控件。因此，在我看来，您不需要TDD，也不需要更精确的视图单元测试。尝试为视图编写单元测试不会有多大价值。
使用UI测试框架(如Selenium(或您自己的UI测试框架来测试用户交互，可以更有效地测试View。通过这种方式，您可以获得比尝试TDD View层更多的投资回报(ROI(。
我对斯波克的回答没有太多补充。编写测试应该有助于将来代码的开发和维护。如果他们阻碍了，那么要么代码的架构不正确，要么是ROI低的代码。
一个值得一提的模式是谦逊的观点。有几种方法可以处理它，每种方法都有不同的权衡，但要点是让数据结构定义视图的外观，然后让视图读取这些数据结构并从中设置其属性。
这允许您测试驱动视图的数据结构是否正确生成，而不必测试视图本身，因为它只是一个读取和设置值的普通对象。