外部项目的单元测试

发布于 2024-07-13 16:16:21 字数 210 浏览 5 评论 0原文

我试图就人们在单元测试和子(或外部)项目方面所做的事情达成共识。

希望我会用一个例子来澄清。 我有一个项目 P1,它依赖于另一个项目 P2。 P2有自己的单元测试和发布周期。 P1 也有自己的单元测试。 问题是 P2 的单元测试是否应该作为 P1 单元测试的一部分包含/运行,还是应该仅在 P2 发布时运行 P2 单元测试?

清澈如泥。 基思.

I'm trying to get a concensus of what people do with regard to unit tests and sub (or external) projects.

I'll, hopefully, clarify with an example. I have a project P1 that relies on another project P2. P2 has its own unit tests and release cycle. P1 has its own unit tests as well. The question is should the unit tests for P2 be included/ran as part of P1's unit testing or should P2 unit tests be ran only when P2 is being release?

Clear as mud.
Keith.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

君勿笑 2024-07-20 16:16:21

当 P1 运行时,无需运行 P2 的测试。 如果 P2 的代码没有更改,那么在此期间再次运行测试不会带来任何好处。

如果 P2 由于 P1 的测试而中断,则需要对 P2 进行更多单元测试,以确保您有足够的覆盖范围(或者可能存在接口问题,这完全是另一个问题)。

There's no need to run P2's tests when P1's are run. If P2's code hasn't changed, running the tests again during would provide no benefit.

If P2 breaks because of P1's tests, then more unit tests for P2 are required to ensure you have sufficient coverage (or perhaps you have an interface problem, which is a different issue entirely).

ヤ经典坏疍 2024-07-20 16:16:21

理论上,如果 P2 的单元测试良好,那么您不需要运行它们。

但是,如果您确实运行它们,则由于环境的差异,您有可能(可能很小)使它们失败。 如果运行它们的成本很低,为什么不呢? 但是,如果测试的设置很复杂,您需要额外的数据库或其他东西,那么可能不值得这么痛苦。

您可能需要对使用 P2 的代码进行集成测试,以测试您使用的特定功能的行为。 如果您正在使用 P2,并且 P2 以某种微妙的方式发生变化,那么您怎么知道。 如果 P2 有不同的发布周期,那么这一点尤其重要:你不知道它们破坏了什么:-)

Theoretically, if the unit tests for P2 are good, then you shouldn't need to run them.

However, if you do run them, there is a (maybe slight) chance that you will make them fail, through a difference in environment. If the cost of running them is low, why not? If however, the setup for the tests is complex, you need an extra database or something, then it's maybe not worth the pain.

What you may need are integration tests for the code that uses P2 that tests for the behaviour of specific functionality that you use. If you're using P2, and P2 changes in some subtle way, then how do you know. If P2 has different release cycles, then this is especially important: you don't know what they've broken :-)

以为你会在 2024-07-20 16:16:21

执行 get 时运行它们。 如果代码是从源代码控件中实时检索的,那么也请运行它们。
另请注意,您可能需要像 P1 上那样针对 P2 的使用进行一些集成测试。

Run them when doing the get. If the code is being retrieved live from the source code control, then do run them as well.
Also note that you might want to throw in some integration tests as on P1 regarding the use of P2.

久夏青 2024-07-20 16:16:21

我在客户端和服务器的情况下都有过类似的经历。 即客户端与网络服务。 这两个组件都已进行单元测试。

P2 测试基于 P1 是固体的假设。 反对 P1 版本是个好主意。 但运行 P2 和 P1 来发现更多潜在问题也没什么坏处。

I had similar experiences in the situation of client and server. i.e. client vs web service. Unit testings had been in place for both of the components.

P2 tests is based on assumption that P1 is solid. It is good idea to run against P1 release. But it doesn't hurt to run P2 and P1 to find more potential problems.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文