如何使用 Ivy 进行构建和单元测试？
使用 Ivy 进行单元测试时，最佳实践是将测试依赖项放入您正在构建的目标二进制文件的 Ivy.xml 文件中吗？或者它们应该位于您正在构建的测试项目的单独的 Ivy.xml 文件中？
我在 Jenkins 构建服务器上使用 Ant 构建文件。
最初，我计划在目标二进制文件构建后运行单元测试项目，但后来我上传到 Artifactory 时感到困惑，因为最后的 ivy 解析是针对测试依赖项完成的，而不是针对目标二进制文件。
如果我将测试依赖项放在实际二进制文件的 Ivy.xml 中，则会收到以下错误：
“模块无权依赖自身”
...但我的测试取决于我正在构建的目标二进制文件。
测试项目的 Ivy.xml 文件是否应该实际将目标二进制文件列为依赖项？
更新
我现在在目标二进制文件的 Ivy.xml 中有依赖项。
我已将新的依赖项标记为具有“测试”配置，以将它们与目标二进制文件所需的依赖项区分开来。
我现在正在研究如何将我的测试项目指向目标项目构建生成的二进制文件。我不确定这在技术上是否是 Ivy 的问题。
构建目标二进制文件后，我是否应该有从测试项目到目标二进制文件的相对路径引用？
另一个想法是将目标二进制文件发布到本地缓存，然后在目标项目中引用它。
更新 2
我最终使用 ant 复制任务将从目标项目构建的二进制文件复制到其中包含目标项目依赖项的文件夹。由于测试项目依赖项位于此文件夹中，因此目标项目可以找到目标二进制文件。
When unit testing with Ivy, is it best practice to put the test dependencies into the Ivy.xml file for the target binary you are building? Or should they be in a separate Ivy.xml file for the test project you are building?
I'm using Ant build files on my Jenkins build server.
Originally I planned to run the Unit test project after the target binary's build, but then my uploads to Artifactory got confused as the last ivy resolve was done for the test dependencies, not the target binary.
If I place the test dependencies in the actual binary's Ivy.xml, I get the following error:
"a module is not authorized to depend on itself"
...but my test depends on the target binary that I'm building.
Should the test project's Ivy.xml file not actually list the target binary as a dependency?
Update
I have the dependencies now in the target binary's Ivy.xml.
I've flagged the new depencencies as having a "test" configuration to set them apart from the dependencies needed for the target binary.
I'm now working out how to point my test project at the binary produced by the build of the target project. I'm not sure if this is technically an issue with Ivy.
After I build the target binary, should I have a relative path reference from the test project to the target binary?
Another idea is to publish the target binary to the local cache, and then reference it from there in the target project.
Update 2
I ended up using the ant copy task to copy the binary built from target project to the folder with the target project's dependencies in it. Since the test project dependencies are in this folder, the target project can locate the target binary.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
同意 Mark O'Connor 的评论：
单元测试的最佳实践通常是在打包之前对已编译的代码运行测试。
我建议将您对单元测试的调用作为编译之后、打包之前的一个步骤。大多数时候，如果测试失败，您不希望将代码打包并上传到工件管理器（除非您有某种形式的特殊情况）。
所有这些都意味着测试应该在同一个 Jenkins 作业中进行。您可以构建这两个 DLL，让它们使用相对路径相互引用，并执行测试，所有这些都在同一个作业中进行。然后您可以将二进制文件上传到 Artifactory，并确信它通过了测试。
Agreeing with Mark O'Connor's comment:
Best practice with unit testing in general is to run the tests on the compiled code before packaging it.
I would recommend including your call to your unit tests as a step after compilation, and before packaging. Most of the time, you don't want to package and upload code to an artifact manager if it has failing tests (unless you have some form of special circumstances).
All of this implies that the tests should occur in the same Jenkins job. You can build both DLL's, have them refer to each other using relative paths, and execute tests, all in the same job. Then you can upload your binary to Artifactory, confident that it passes tests.