我们有这样的业务流程
- 从数据库获取列表数据
- 对于列表中的每个项目
- 将项目转换为 JSON
- 将数据发送给第三方以获得结果
- 将结果保存到数据库
Send data会因第三方而异，一个需要使用HTTP，一个需要使用FTP或gRPC调用。我使用接口将发送数据抽象到第三方，并让 API(外部层(决定它想要使用哪种方法。
该架构遵循清洁建筑师。我们在中间有实体、业务/核心，以及 API 和基础设施的包装器。
代码示例
In Business/Core project
// Abstract class
var items = await GetItemsAsync(args); // abstract method
foreach (var item in items)
{
var json = await ConvertItemToJsonAsync(item); // abstract method
var resultInString = await SendAsync(json); // abstract method
await SaveResultAsync(item, resultInString); // abstract method
}
// Now for child classes, they will implement those abstract methods.
// In this case, it will be
override Task<string> SendAsync(string json)
{
return _thirdparty.SendDataAsync(json);
}
interface IThirdParty
{
Task<string> SendDataAsync(string json);
}
这意味着子类将接受一个名为 _thirdparty 的接口，以分离发送数据到第三方。在API层中，很容易创建某些类型的第三方，例如通过HTTP，FPT或gRPC发送，并注册DI或更好的工厂使用。
我关心单元测试，当你编写单元测试时，你需要一个上下文，有了上下文，你知道编写测试用例/脚本的单元是什么。 例如，如果我们创建一辆汽车，上下文是一辆基本上可以驾驶的汽车。我们应该关心使用什么样的轮子螺丝吗？它来自供应商的零件装配护理。如果我们测试组件的每个部分，我们需要关心螺钉。这是一个背景。如果遵循上述方式，我可以轻松地为每个抽象方法编写一个单元测试，对于整个流程，我可以为第三方创建一个模拟接口。
但是 Business/Core 有一个问题，因为这个业务的重点是调用第三方，这是一个上下文，其余的方法都在处理 db，我们不需要测试。
为了让我可以在业务/核心中测试流程，我需要将第三方的具体类从 API 移动到业务/核心，然后我可以作为一个单元进行测试。通过这样做，Business/Core现在需要使用称为HttpClient的东西，gRPC类来与第三方合作。
我的问题是，如果网络是其业务，企业应该关心网络吗？或者我们有更好的方法来解决它吗？
这个问题和(我的(答案是固执己见的。
如果你构建一个系统(或者作为你的比喻一个汽车(，你将需要多层测试。单元测试是测试的最低杠杆，其主要目的是测试代码的实现细节。它们是维护代码库的开发人员的工具和开发周期的一部分。
话虽如此;我认为您不应该在"汽车可以驾驶"上应用单元测试(这些更有可能是集成和回归测试(，您应该在"螺钉和螺栓"级别应用单元测试。
我认为你应该对核心逻辑进行单元测试，即使它只调用第三方API。我敢打赌，事情的顺序和错误处理在该代码中很重要。
但就像我说的，这些只是我的意见。
但我想，如果代码有单元测试，那么在几年内重构代码逻辑的未来开发人员会很感激......因此，这个未来的开发人员可以是你自己。