通常，当使用依赖注入时，单元（和其他）测试负责创建/模拟被测系统的相关性并注入它们。向测试注入依赖关系
但是，有时测试本身具有依赖性，或者需要将依赖关系注入到SUT中，而它本身不能创建。例如，当测试与数据库交互的类时，测试需要知道连接字符串和目录名等，这些不能被硬编码，因为对于运行测试的每个人来说它们不一定相同。
那么，你会如何建议测试找出这些设置？做一些xUnit风格的测试框架提供了一种给测试用具提供依赖性的方法吗？在运行所有测试之前，测试类是否应该具有静态属性？该测试是否应该忽略DI实践并从全球某个地方去获取依赖关系？其他建议？
当你使用单元测试框架做集成测试，你真的没有一个DI或单元测试的问题。
你有什么是集成测试是利用高功率的单元测试框架。
因为它们是集成测试，他们是从单元测试的种类不同。 “独立性”不再是真正的数字。
获得集成测试设置，从用户而异，最好的办法是让他们以同样的方式最终应用会得到他们。如果你使用Java，你可能有一个属性文件。在Python中，我们有用于集成测试的特殊Django设置文件。
完全自动化测试的原理：您应该能够从源代码控制库中下载所有源代码，并运行测试。考虑到环境（机器）具有正确的安装基础（即编译器，测试框架，数据库引擎，如果相关等），测试负责在执行测试用例之前设置其Fixture。
这意味着，对于数据库，试验应该
后如果再次删除数据库，出于某种原因，你不能这么做，你唯一能做的就是在你的源代码控制系统中有一个配置文件，它包含你的测试中所有机器的特定机器条目invironment;例如对于机器Tst1连接字符串是一个值，但对于Tst2这是另一个值。
这会变得非常恶劣真的很快，所以它更容易有测试负责夹具的安装和拆卸，因为这意味着他们可以简单地使用现场产生的硬编码值，或者价值观。
这真的没有任何关系与DI ...
DI战斗与依赖条件的复杂性，而您的单元测试必须是大部分时间非常简单。典型的单元测试将检查一个孤立类的一个孤立的方面。而不是你创建mock的所有依赖，并且（通常）通过CUT（Class Under Test）构造函数注入它们。这里通常不需要DI框架。
但是。显然，一些更高级别的测试可能仍然需要非模仿依赖。例如，您希望对大量数据进行测试，并且不想创建特殊的假数据源，以便将其保存在真实的数据库中（也可以使用该数据执行一些UI测试）。在这种情况下，我仍然会尽量保持尽可能简单，在课堂设置/测试设置方法中初始化测试。
你看，你需要小心点。无论您何时进行大型复杂测试，您都可以：
等等