单元测试ViewController的生命周期

Question

我正在为我的ViewControllers编写单元测试.viewDidAppear:,viewWillAppear:等方法的最佳实践是什么？

我正在使用调用viewDidLoad的[vc view].但除了viewDidLoad之外,我应该如何对其他生命周期方法进行单元测试.对它们进行单元测试是否常见？直接调用它们是否有意义？喜欢:

[vc viewWillAppear:NO];
[vc viewDidAppear:NO];

谢谢

Answer 1

有很多开发人员要么回避，要么不相信您可以测试 UIViewController。苹果糟糕的测试 doco也无济于事。

UIViewController 非常易于测试，您可以采用多种方法。

首先，正如任何人都会告诉您的那样，尝试将业务逻辑排除在视图控制器之外。尝试使其仅加载视图，并尽可能少地执行其他操作。从 MVC 架构更改为其他架构可能会对此有所帮助。根据您正在构建的内容，您可能还需要考虑使用自定义 UIView 类来提供帮助。

纯单元/逻辑测试

你正在处理苹果所谓的“逻辑测试”，即没有分配可执行文件的测试目标。您仍然可以进行很多测试。包含简单视图处理代码的方法可以通过手动设置视图或使用测试代码手动加载 xib 文件等进行测试。诸如OCMock之类的模拟框架也非常有用。

但通常情况下，在此类测试中，您最终需要手动使用各种生命周期方法来执行要测试的代码。例如，如果您想测试一个viewDidLoad方法：

id mockView = OCMClassMock([UIView class]);
// Setup mock expectations.
myViewController.view = mockView;
[myViewController viewDidLoad];

应用测试

如果您使用已设置应用程序的测试目标，那么您实际上可以通过单元测试进行一些测试，而无需尝试导航应用程序。这有点作弊，但我发现它有时非常有用。

UIView *myView = // ... load the view manually or simply [[UIView alloc] initWithFrame:CGRectMake(0,0,100,100)]  
myViewController.view = myView;
[[UIApplication sharedApplication].keyWindow addSubview:myView];

如果采用这种方法，请务必删除拆卸中的视图。这样做的优点是，系统会自动为您调用有关在屏幕上获取视图的所有生命周期方法。

大多数情况下，我发现这对于与视图控制器和自定义视图相关的测试很有用，这些视图与属于较大屏幕布局的一部分的视图有关。没有那么多顶级视图控制器。

用户界面测试

最后是苹果提供的新的 UI 测试框架。我过去使用过第三方 Ruby 框架，例如 Frank 和Calabash 。事实证明，Apple 的 UI 测试实际上非常好，并且与这些工具相当。

它的技巧是使用它来构建一个有意义的方法库，并帮助描述（使用 DSL）应用程序的各个方面。

这种方法的缺点是您不能只加载要测试的视图。您必须实际运行该应用程序并导航到它。另一个主要缺点是它很大程度上基于应用程序的外部可访问性视图。几乎不可能了解内部结构，因此测试基于应用程序在屏幕上的行为而不是内部类。

到目前为止，我还没有探索混合这种形式的测试和手动将视图加载到窗口上的想法，但我不明白为什么这不起作用。

Answer 2

您刚刚感受到了 iOS ViewController 的一大缺点：它们的可测试性很糟糕。

\n\n

\n

MVC 的另一个大问题是它阻碍开发人员编写单元测试。由于视图控制器将视图操作逻辑与业务逻辑混合在一起，因此为了单元测试而分离出这些组件将成为一项艰巨的任务。许多人忽略了一项任务，而倾向于\xe2\x80\xa6，只是不测试任何东西。

\n

\n\n

来源

\n\n

不要测试 UIKit！你应该测试一下你自己的逻辑。将逻辑放入 VC 中会使测试变得非常困难。尝试将其放在其他地方并单独进行单元测试。答案是：您应该避免通过调用 UIKit 方法进行测试 - 特别是这些方法不是设计为直接调用的！

\n\n

如果你把所有的逻辑都从 ViewController 中取出，它就会真正成为一个视图：一个在屏幕上显示某些内容的哑类。那里应该没有什么可以测试的。

\n\n

也许你应该考虑使用 MVVM/MVP/VIPER 来代替。请阅读提供的链接，它将解释一切。

\n