我正在使用OpenWrap 2.0的测试版。 OpenWrap包含运行单元测试的支持，我的问题是这究竟是如何工作的？
我是否应该将其视为采用内置包装的测试运行器，搜索包含中包含的测试并尝试运行它们？是否需要在包装内包含测试？
依赖项如何解决在测试环境中的工作？我可以指定一个测试范围，它增加了测试所需的额外依赖关系。这些依赖项何时使用？我假设它用于构建测试项目，并使用测试包装运行测试？但是，当我在包装中包含测试时，那些测试范围的依赖项是否也不应被视为包装的依赖项，或者它们是否仅在我尝试执行“test-wrap”时用作依赖项？
我在测试环境中想知道的另一件事是编译时和运行时依赖之间的区别。
作为示例，我有一个指定API的项目API。在该项目的旁边，我有另外两个项目Impl1和Impl2，每个项目都指定了该API的不同实现。接下来我有一个测试项目API.Tests包含针对API的测试。测试使用依赖注入来注入Impl1或Impl2来运行测试。 在这种情况下，API.Tests项目仅对API具有编译时依赖性（并且应该只具有编译时依赖性）。但是，在运行测试时，项目对Impl1或Impl2具有运行时依赖性。有关如何打包的任何建议吗？
答案 0 :(得分：0)
test-wrap将能够运行测试运行器，用于作为pacakge的一部分进行测试（在/ tests中）。
现在的实现不再是最新的，主要是因为软件包不包含testdriven.net测试运行器，这使得运行这些测试相当复杂。由于这个原因，我还没有重新评估我们的计划。
OpenWrap 2使用范围来定义仅适用于代码的某个子集的依赖项。在测试的情况下，如果您在描述符中有正确的dicrectory-structure指令，您的项目将在正确的范围内引入这些依赖项。
那就是说我们不会在程序集中保留那些信息，所以当你运行那些测试时我们不会加载测试范围的依赖关系，我们应该这样做（至少对于测试来说）。但是，程序包中的所有程序集都是在当前的appdomain中注入的，因此对于您的场景，如果您在/ tests中进行了测试，则只需将所有这些程序集打包在同一个程序包中，它就可以正常工作。
同样的机制