【问题标题】:Using a dependent project for test objects为测试对象使用依赖项目
【发布时间】:2020-12-26 11:46:50
【问题描述】:

假设我有多个java项目,都使用maven:Project A和Project B

  • 项目 A 是一个库

  • Project B是一个使用Project A

    的应用程序

两个项目同时开发。 Project A 的新要求已通过 Project B 的新版本得到满足。

我主要是手动测试我的代码 - 正如预期的那样 - 产生的代码覆盖率和质量都低于最佳水平。

因此,我目前正在研究使用 Junit 为我的项目编写测试。由于 Project A 主要定义接口,因此我必须 - 至少我相信如此 - 在测试代码中编写这些类的实现。

由于我已经在 Project B 中定义了这些接口的实现,我想我可以在 Project A 中使用 Project B 作为 test 依赖项>,乍一看这很有意义,因为 Project A 的几乎所有功能都在这些实现中使用,因为我(至少目前)不会在 Project A 未在 项目 B 中使用(请记住:这可能会在未来的项目中发生变化,例如 新创建的项目 C,这也可能取决于项目 A)。

另一方面,这会产生某种循环依赖。在 Project Bpom.xml 中,我将定义对 Project A 的常规依赖,而 Project A 将依赖于 test-scope 中的项目 B

因此提出以下问题:

  • 这在技术上是否可行,或者我是否会从一开始或以后遇到循环依赖问题? (我相信我见过有人在做类似的事情,他们必须在 Project A<dependencyManagement> 部分中定义正确版本的 Project A 以确保当前代码是在测试时使用的,而不是 Project B 中定义的版本。虽然我找不到它了,所以我无法验证这一点,但我记得对为什么他们感到困惑将在该部分定义他们自己的项目版本编辑:我相信我又找到了它,但它似乎是别的东西,我可能只是在研究 junit 和测试时有点困惑;) )
  • 是否需要为测试用例的类使用下游项目,或者我以后可能会遇到问题? (我的第一个想法是,一旦我在 Project B 中将 Project A 替换为第三方依赖项,我就会遇到问题,因此丢失了我所有的测试用例项目 A

【问题讨论】:

    标签: java maven testing dependencies code-coverage


    【解决方案1】:

    不,这不是一个好主意。

    首先,您创建循环依赖项。其次,你不测试你想测试的东西,即项目 A(不是项目 B)。

    那么,你会怎么做呢?

    首先,想想如果同时开发两个独立的项目A和B是否真的明智。你可以把它们放到一个多模块项目中。

    其次,如果A主要是接口,那么测试B(与A集成)可能更明智,而不是单独测试A。如果你发现 A 中有值得测试的东西,你可以使用 mocking(比如 mockito)来模拟出现在你的测试中的接口。

    【讨论】:

    • 只需在 A 中使用单元测试来测试 A 中的代码,在 B 中使用单元测试来测试 B 中的代码。如果您最终得到的项目 C 也实现了来自 A 的接口怎么办?显然,这将需要与实现 B 不同的测试套件,因此测试属于实现所在的位置,而不是接口所在的位置。
    • 感谢您的回复!也许我应该澄清一下,因为我不完全确定以上是否适合我的情况:这些接口使用反射(例如,以某种方式序列化对象)。据我所知,只是模拟接口会/应该产生一个空的序列化。测试 B 与 A 的集成听起来是个好主意,但无论如何可以从 CI 工具(如 github 操作)自动运行这些测试? A 中的测试会在 A 的构建过程中自动运行,在项目 B 中编写的测试不会在 A 的构建过程中运行。
    • 模拟可以产生任何类型的响应,具体取决于上下文。您可以使用同时测试 B 和 A 的 JUnit 测试。这些将在 B 的构建过程中运行。
    • 一起测试 A 和 B 对我来说可能没有用,因为我想知道我的代码中的添加是否会在我推送到 github 后立即破坏任何东西。但我会更深入地研究一下对项目 A 的模拟。谢谢。
    • 如果这些项目紧密耦合,最好将它们作为多模块项目在一个 git 存储库中管理。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2011-08-04
    • 2012-01-01
    • 2012-07-15
    • 1970-01-01
    • 2016-11-24
    相关资源
    最近更新 更多