iphone – 单元测试 – 要测试什么？

2023年4月6日 239次阅读

所以,我已经完成了一些关于单元测试和在
Xcode中创建测试用例/套装的优点的阅读.我可以看到这样做的好处,可以避免像回归这样的事情,并确保新的提交/构建不会破坏现有的代码.

我想弄清楚的是 – 我测试什么？

我是否为我创建的每个类创建测试？

目前,我正处于项目的开始阶段,我正在忙于创建大量的模型对象 – 这些类没有那么多 – 主要是为了保存我解析的数据(来自XML).我应该创建测试用例以确保满足每个对象的每个要求吗？

以上面的例子为例 – 如果我为我的一个模型对象写了一个这样的测试套装：

import <XCTest/XCTest.h>
#import "BBError.h"

@interface ErrorObjectTests : XCTestCase

@end

@implementation ErrorObjectTests
{
    BBError *error;
}
- (void)setUp
{
    [super setUp];
    // Put setup code here; it will be run once, before the first test case.
    error = [[BBError alloc]init];
}

- (void)tearDown
{
    // Put teardown code here; it will be run once, after the last test case.
    [super tearDown];

   error = nil; 
}


-(void)test_HasValidErrorCodeMessage
{
    error.code = @"Error Code";

    XCTAssertEqual(error.code, @"Code error",
                   @"BBError should have valid error code message");

}

现在如果由于某些原因在我的应用程序中 – 我将error.code设置为nil或者不为其分配错误代码 – 此测试会失败吗？

我无法理解为什么它会失败 – 因为在实际的测试方法中 – 我将error.code分配给字符串值.我应该保留这个值,然后我使用这个对象,确保error.code有一个值,以便测试通过？

P.S：是的,我知道这个特定的测试可能不是最准确的,因为我可能并不总是首先得到错误 – 但这只是一个例子

欣赏任何输入的人.

最佳答案 当您开始进行单元测试时,最重要的是编写它们.很容易在开始时大肆宣传,然后逐渐放弃这个想法,因为截止日期,不可测试的代码,缺乏同事的支持以及什么不是,特别是如果你对测试所有事情感到震惊或者之前得到99％的覆盖率建议.最好保持务实,专注于最有可能受益的领域,比如说：

>测试关键应用程序功能(大多数业务逻辑)
>测试你期望的东西可能会有问题/过去证明是有问题的
>通过其他方式测试难以/耗时测试的东西
>不要测试数据持有者对象(如POCO);它们很少带有任何逻辑,在测试它们时几乎没有增值

通过这些点走你的error.code测试示例并尝试自己决定.

例子

Test critical application features (majority of business logic)

有人可能会争辩说,任何对应用程序工作/功能都不重要的代码都不应该存在.这可能听起来很吸引人,但事实是,有很多代码可以帮助开发人员的生活,或者帮助解决不一定有助于功能开发的常见问题.你测试这样的代码吗？并不总是 – 如果我重构了一个将3个语句组合成一个的方法,因为它们通常一起被发现,我可能想跳过测试.

Test stuff that you expect to be problematic/has proved to be problematic in past

这很简单.我们致力于有限的资源(即时间);在现实世界的情景中,测试一切往往是太田园诗般的想法.很多时候,你会发现自己必须做出决定,无论一段代码是否会编写测试.当这样的时候到来时,喜欢复杂的代码比简单的代码.确定某些事情是否复杂当然是判断力,在很大程度上取决于你的经验.但我想大多数人都可以对以下哪种方法可能更难以处理：

PrintLineToFile(string filePath, string line)
ComputeUserRisk(User user, RiskAssessment previousResult)

另外,如果我可以快速查看简单的代码片段,并且确信它能够像我期望的那样工作,那么我可能会跳过单元测试(但同样,这是在紧迫的期限/稀疏中的判断调用 – 资源时间).

Test stuff that is difficult/time-consuming to test by other means

事实上,只需运行应用程序并单击按钮/执行命令,人工测试人员就可以对所有内容进行半自动测试.但请注意,某些代码很难获得.如果为了测试NumbersConverter,您需要将文件上传到服务器,加载任务创建者,构建新任务并安排它从现在开始运行30秒,因为这是您需要连接调试器的最短时间……那么您应该考虑使用单元测试这样的NumbersConverter,并且每次返回3.15而不是3.16时都不要手动运行完整的场景.

结论

不幸的是,没有“做到这一点,也没有做到” – 规则 – 你必须根据项目类型,领域,团队,工具和许多其他因素来发展自己的方法.一些项目/领域需要更严格的测试,其他项目/领域允许更多的松弛与所有事情一样,总是试着查看你正在做的事情的背景(单元测试),并尝试预测哪些行动(测试)在给定时间(以及适应)最有利于你.

点赞