SOLID和单元测试。使用语言提供的方法/类

Question

所以我读过这个名为SOLID（混合了）Writing Testable Code的东西。然后特别关于D部分。在使用语言库提供的原始类型或方法/类时，如何遵循这些准则。

是否还需要对数组（java（new int[64]）或类成员（例如FileWriter？）使用依赖注入？这些需要使用DI注入还是可以class仍然实例化它们？

您应该在多大程度上遵循上述准则？

我不是在寻找特定于语言的答案（如果可能的话）。恕我直言，答案应该适用于，例如PHP，Python Java，heck，甚至C

Answer 1

您通常不会注入基元或DTO / POJO - 类似对象。原因是：

1. 没有太多业务/域逻辑的简单价值持有者
2. 在没有任何额外工具的情况下轻松存根（为测试创建假数据阵列不成问题）

FileWriter是不同的，因为它与上述要点完全相反。我不能简单地在测试中将其存根并使其工作而没有很少的强假设 - 比如，我假设每个运行此代码的未来开发人员都会在他的机器上有某个文件。对于单元测试，这通常是 no-go ，也是在这些情况下应用DI的原因之一。

这些问题来自于FileWriter在两个不相关的组件（您的应用程序和文件系统）之间充当通信点的事实。在大多数情况下，任何进行此类集成的类（在您的应用程序和数据库/网络/文件/ REST等之间）都应该被抽象和注入。

Answer 2

注入数组是过度的。注入文件编写器是绝对必要的。事实上，注入作者是不够的。文件编写者与外部世界进行了大量的交互，你不希望这样。文件编写器应该包装在自己的类中，永远不要直接调用。

相反，注入FileWriterWrapper的接口。因此，依赖性受到控制。此外，单元测试中的文件交互是一个主要的痛苦。不惜一切代价避免它。数据库交互也是如此。实际上，所有与外部世界的交互都应该在单元测试中进行存根/模拟。

美丽的是，SOLID设计和可测试性齐头并进。好的设计意味着可测试的代码。如果您发现很难测试某些代码，通常表明您的设计存在缺陷。