Question

正如我之前听到的，最近在Jon Reid's very good screencast，一些init方法或iOS应用程序中学到的，viewDidLoad方法往往变得越来越大。我试着重构这个方法：

- (void)viewDidLoad {
    // 10+ lines of setting default property

    // 20+ lines of setting up the navigation bar

    // 20+ lines of resetting the view hierarchy
}

这被一个非常好的简短方法所取代，该方法包含对具有说话名称的其他方法的调用：

- (void)viewDidLoad {
    [super viewDidLoad];

    [self setDefaultResourceNames];
    [self setupRightBarButtonItems];
    [self restoreNavigationControllerHierarchy];

    [[NSNotificationCenter defaultCenter] addObserver: (...)];

}

现在这三种方法正在进行单元测试，这比以前好多了。现在我的问题是，是否应该测试viewDidLoad方法？

为了做到这一点，我对我的班级进行了部分模拟，并编写了以下测试：

- (void)testViewDidLoadShouldInstantiateControllerCorrectly {
    NewsItemDetailsViewController *sut = [[NewsItemDetailsViewController alloc] init];
    id mockSut = [OCMockObject partialMockForObject:sut];
    [[mockSut expect] setDefaultResourceNames];
    [[mockSut expect] setupRightBarButtonItems];
    [[mockSut expect] restoreNavigationControllerHierarchy];

    [mockSut viewDidLoad];

    [mockSut verify];
}

这有什么用吗？这似乎很大程度上与实际的源代码和方法执行有关，而不是通过调用方法引起的效果（实际上，就我所知，这实际上是单元测试的内容）。但调用该方法的效果实际上包含在三个单元测试中，测试子方法。

进行此测试是否合适？或者在所有其他呼叫都已经过测试时是不必要的？

Answer 1

这取决于您正在测试的内容。这里没有一般的解决方案;你需要根据自己的专业判断做出决定。

在这种情况下测试控制流程或为其提供回归安全网是否有益？这些好处是否超过了成本？

基本上不鼓励为了一致而嘲笑。在大多数情况下，它已被证明是有害的。将它用作实际需要它的工具。

Answer 2

这是一种非常合理的方法。你想测试两种类型的东西：1）你不想破坏的东西，2）你想要记录的东西。如果这种方法符合这些标准中的任何一个或两个，那就没问题。

我认为像这样的测试的主要缺点是它们可以为不言自明的东西增加大量的编码开销。查看设置代码通常非常易读 - 您可以浏览它并了解正在发生的事情，因此测试不会增加太多的文档值。如果视图是您每次使用应用程序时使用的视图，那么当您执行QA时，如果任何视图设置被破坏，可能会立即清楚，因此测试不会增加很多防御性编码值。

最后，你是那个维护这段代码并负责修复它的人，因此你需要确定测试工作现在是否会超过风险。

测试一个已经重构的方法（分成多个方法）？

2 个答案: