objective-c – 测试一个已经重构的方法(分成多个方法)？

2023年5月24日 195次阅读

正如我之前听说过的,最近在
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];
}

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

所有其他电话都在测试之前,进行此测试是否合适？

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

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

最后,您将是维护此代码并负责在其中断时修复它的人,因此您需要确定测试工作现在是否会超过风险.

点赞