OpenWrap：测试包装，它是如何工作的？
我正在使用 OpenWrap 2.0 的测试版。 OpenWrap 包含对运行单元测试的支持，我的问题是它到底是如何工作的？
我是否应该将其视为一个测试运行程序，它采用构建的包装，搜索包装中包含的测试，并尝试运行它们？是否需要将测试包含在包装内？
在测试环境中依赖关系解析如何工作？我可以指定一个测试范围，它添加测试所需的额外依赖项。什么时候使用这些依赖项？我假设它用于构建测试项目，并使用 test-wrap 运行测试？但是，当我确实将测试包含在包装中时，这些测试范围的依赖项是否也应该被视为包装的依赖项，或者它们是否仅在我尝试执行“test-wrap”时用作依赖项？
在测试的上下文中我想知道的另一件事是编译时依赖项和运行时依赖项之间的差异。
例如，我有一个指定 API 的项目 API。在该项目旁边，我还有另外 2 个项目 Impl1 和 Impl2，每个项目都指定该 API 的不同实现。接下来，我有一个测试项目 API.Tests，其中包含针对 API 的测试。测试使用依赖项注入来注入 Impl1 或 Impl2 以运行测试。 在这种情况下，API.Tests 项目仅具有对 API 的编译时依赖项（并且应该仅将其作为编译时依赖项提供）。然而，在运行测试时，项目对 Impl1 或 Impl2 具有运行时依赖性。关于如何打包这个有什么建议吗？
I am using the beta of OpenWrap 2.0. OpenWrap contains support to run unit-tests, my question is how exactly does this work?
Should I see it as a test-runner that takes a built wrap, searches for the tests included in the wrap, and tries to run them? Is it required to include the tests inside the wrap?
How does the dependency resolving work in the context of tests? I can specify a tests-scope which adds extra dependencies required for the tests. When are those dependencies used? I assume it is used to build the test-projects, and to run the tests with test-wrap? However, when I do include the tests in the wrap, shouldn't those test-scoped dependencies also be considered dependencies for the wrap, or are they only used as dependencies when I try to execute "test-wrap"?
Another thing I was wondering about in the context of the tests, is the difference between compile-time and run-time dependencies.
As an example, I have a project API that specifies an API. Next to that project, I have 2 other projects Impl1 and Impl2 that each specify a different implementation of that API. And next to that I have a test project API.Tests that contains tests against the API. The tests use dependency injection to inject either Impl1 or Impl2 to run the tests.
In this case, the API.Tests project only has a compile time dependency on the API (and should only have that available as a compile time dependency). When running the tests however, the project has a run-time dependency on Impl1 or Impl2. Any suggestions on how to package this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
test-wrap 将能够为作为包的一部分（在 /tests 中）提供的测试运行测试运行程序。
现在的实现不再是最新的，主要是因为包不包含 testdriven.net 测试运行器，这使得运行这些测试相当复杂。由于这个原因，我还没有重新评估我们的计划。
OpenWrap 2 使用范围来定义仅适用于代码的特定子集的依赖项。在测试的情况下，如果描述符中有正确的目录结构指令，您的项目将在正确的范围内引入这些依赖项。
也就是说，我们不会在程序集中保留该信息，因此当您运行这些测试时，我们不会加载测试范围的依赖项，而我们应该这样做（至少对于测试而言）。然而，包中的所有程序集都被注入到当前的应用程序域中，因此对于您的场景，只要您在 /tests 中进行测试，您只需将所有这些程序集打包在同一个包中，它就应该可以工作。
同样的机制将
test-wrap will be able to run a test-runner for tests that are shipping as part of a pacakge (in /tests).
The implementation right now is not up-to-date anymore, mostly because packages do not include the testdriven.net test runner, which makes running those tests rather complicated. I've not re-evaluated our plans for this yet because of this reason.
OpenWrap 2 uses scopes to define dependencies that only apply to a certain subset of your code. In the case of tests, provided you have the correct dicrectory-structure instruction in the descriptor, your project will pull in those dependencies in the correct scope.
That said we don't preserve that information in the assembly, so when you run those tests we don't load up the dependencies for the test scope, which we should probably do (at least for tests). All assemblies in your package are however injected in the current appdomain, so for your scenario, provided you have your tests in /tests, you just need to package all those assemblies in the same package and it should just work.
The same mechanism will