1

我正在使用 OpenWrap 2.0 的测试版。OpenWrap 包含对运行单元测试的支持，我的问题是它究竟是如何工作的？

我是否应该将其视为一个测试运行程序，它需要一个内置的包装，搜索包装中包含的测试并尝试运行它们？是否需要在包装内包含测试？

在测试的上下文中，依赖解析是如何工作的？我可以指定一个测试范围，它添加了测试所需的额外依赖项。什么时候使用这些依赖项？我假设它用于构建测试项目，并使用 test-wrap 运行测试？但是，当我确实将测试包含在包装中时，这些测试范围的依赖项是否也应该被视为包装的依赖项，或者它们仅在我尝试执行“测试包装”时用作依赖项？

在测试的上下文中我想知道的另一件事是编译时和运行时依赖项之间的区别。

例如，我有一个指定 API 的项目 API。在该项目旁边，我还有 2 个其他项目 Impl1 和 Impl2，每个项目都指定了该 API 的不同实现。接下来我有一个测试项目 API.Tests，其中包含针对 API 的测试。测试使用依赖注入注入 Impl1 或 Impl2 来运行测试。在这种情况下，API.Tests 项目仅具有对 API 的编译时依赖项（并且应该仅将其作为编译时依赖项提供）。然而，在运行测试时，项目对 Impl1 或 Impl2 具有运行时依赖性。关于如何打包这个有什么建议吗？

4

1 回答 1

0

test-wrap 将能够为作为 pacakge 的一部分（在 /tests 中）提供的测试运行测试运行器。

现在的实现不再是最新的，主要是因为包不包含 testdriven.net 测试运行器，这使得运行这些测试相当复杂。由于这个原因，我还没有重新评估我们的计划。

OpenWrap 2 使用范围来定义仅适用于代码的某个子集的依赖项。在测试的情况下，如果您在描述符中有正确的目录结构指令，您的项目将在正确的范围内引入这些依赖项。

也就是说，我们不会在程序集中保留该信息，因此当您运行这些测试时，我们不会加载测试范围的依赖项，我们可能应该这样做（至少对于测试）。但是，您包中的所有程序集都注入到当前的应用程序域中，因此对于您的方案，只要您在 /tests 中有测试，您只需将所有这些程序集打包在同一个包中，它应该可以正常工作。

相同的机制将

于 2011-10-31T15:53:26.597 回答