Question

正如预期的那样，在使用TDD（即首先编写测试）时，通常会遇到视图层的问题。

也就是说，为了观察或触发某些可见的更改（布局或样式），我需要公开视图的内部。这会破坏封装，并允许客户端代码执行类似myView.label.text = "User"的操作。

为避免这种情况，我将getter方法添加到UIView类中：

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）添加到增加的覆盖范围内，并在重构时拥有安全网。

考虑到所有这些，我想知道是否还有其他模式或方法，可以用来提高效率，同时保持对代码的信心。

Answer 1

不是Swift方面的专家，但是无论使用哪种语言/框架，都有一些事情告诉我您实际上使您的工作更加困难。

在使用TDD进行视图层跟踪时，我通常会遇到困难。

这是预期的。 View支持非常简单，完全没有任何行为（即域逻辑）。它应该是简单的用户交互，并将数据绑定到视图中的控件。因此，我认为您不需要TDD或围绕View进行更精确的单元测试。尝试为View编写单元测试不会带来太多价值。

可以使用UI测试框架（例如Selenium）或您自己的用于测试用户交互的UI测试框架来更有效地测试View。这样一来，您的投资回报（ROI）会比尝试TDD View层更多。

Answer 2

我对Spock的回答没什么要补充的。应编写测试以帮助将来开发和维护代码。如果他们遇到了麻烦，那么要么代码设计不正确，要么投资回报率很低。

值得一提的模式是humble view。有几种方法可以解决这个问题，每种方法都有不同的取舍，但要旨是要有定义视图外观的数据结构，然后让视图读取这些数据结构并从中设置其属性。

这使您可以测试驱动视图的数据结构是否正确生成，而不必测试视图本身，因为它不过是一个读取和设置值的不起眼的对象。

我应该先为视图层编写测试（在TDD之后），还是只做手动测试，完成后再添加快照测试？

2 个答案: