我一直在阅读有关单元测试的信息。 Clean architecture并尝试实施涉及这两件事的事情。
据我了解,Clean架构的结构使得Interactor对象的方法可以进行单元测试。
但是当用例类似于"创建一个文件,其内容是从某些格式的某些数据中计算出来的时候,我感到很困惑,因为它不是单一的(那里是#)计算文件内容和创建文件,它们都是 in 用例)
这里有一些说明我情况的伪代码:
/* We are in an Interactor (i.e. UseCaseObject)
* This method 1)computes fileContent and 2)writes it into a file.
*/
public void CreateFileFromData(someDataInSomeFormat) {
var parsedData = SomeParser.Parse(someDataInSomeFormat);
string fileContent = ???;
WriteFile(fileContent);
}
我的问题如下:
答案 0 :(得分:2)
您不知道计算数据将从哪里“加载”,但是例如假设数据将从另一个文件中读取。
您的交互者将有三个家属
- 读取文件
- 计算新文件的数据
- 写文件
public class Interactor
{
public Interactor(IReader reader, ICalculator calculator, IWriter writer)
{ }
public void DoJob()
{
var data = reader.Read();
var calculatedData = calculator.Calculate(data);
writer.Write(calculatedData);
}
}
使用这种方法Interactor
将负责“组合”完成任务所需的步骤。
您可以通过模拟所有依赖项来简单地测试Interactor。
其中:
IReader
和IWriter
是网关
ICalculator
是Interactor
交互者中定义的方法必须是单一的吗? (如同,只做 一件事)
方法应该做一件事 - 执行与用例相关的任务。如果任务需要使用网关(外部资源)或任务需要复杂以将其保存在一个方法中 - 您将引入所有必需单元作为依赖项,并且交互器责任将“粘合”它们在一起。
交互者中定义的方法必须进行单元测试吗? (我看到了 功能,单一与否,作为可测试单位,请纠正我,如果 这是不正确的)
仅抽象网关(外部资源) - 然后您可以测试交互器的整个逻辑。如果你先编写测试 - 你将编写测试,整个逻辑可以在一个函数中(它可能/应该是丑陋的spagetti代码,这使得测试通过)。然后,当您看到实施的全貌时,您可以通过将事物移动到专门的课程来开始移动员工。
哪个类必须在Clean中保存fileContent的计算 建筑?
它可以是交互器,如果它是简单的一行计算。但我更喜欢引入专用的计算类并将其作为依赖项引入。虽然测试将保留在交互器中,但专用计算类将通过交互器测试进行测试
答案 1 :(得分:0)
Clean Architecture的一个核心方面是所有应用程序业务逻辑都在Interactor方法中。这意味着你也希望通常使用单元测试和低级验收测试将主要测试重点放在Interactors上。
在设计你的交互式方法时你应该仍然遵循SRP:应该只有一个原因需要改变。 U还可以组合Interactors来跟踪SRP。
如果文件内容的计算是u的应用程序业务逻辑,那么它应该是Interactor方法。
有关Interactors的更详细讨论,请查看我的帖子:https://plainionist.github.io/Implementing-Clean-Architecture-UseCases/