因此，我阅读了一些有关单元测试和在 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 时手动运行完整的场景.
结论
不幸的是，没有“做这个不做那个”的规则 - 你必须根据项目类型、领域、团队、工具和可能的许多来发展你自己的方法其他因素。一些项目/领域需要更严格的测试，而其他项目/领域则允许更多松弛。与所有事情一样，始终尝试查看您正在做的事情的上下文(单元测试)，并尝试预测在给定时间哪些操作(测试)对您最有益(又名适应)。