具体实例方法和静态测试方法一样糟糕,对吗?

发布于 2024-11-07 06:39:00 字数 311 浏览 0 评论 0原文

如果方法 A() 调用静态方法 B(),这很糟糕,因为两者紧密耦合,对吗?

但是,如果 A() 不调用 B(),而是调用某个具体类的非静态方法 C(),这将对于测试同样不利,对吗?因为现在 A() 已耦合到拥有 C() 的具体类。

唯一好的场景发生在使用接口(即依赖注入)并且 A() 调用接口的方法时。

我说得对吗?静态方法不利于测试还有其他原因吗?

If method A() calls static method B(), this is bad because the two are tightly coupled, correct?

But if, instead of calling B(), A() called a non-static method C() of some concrete class, this would be equally bad for testing, correct? Because now A() is coupled to the concrete class that owns C().

The only good scenario happens when interfaces (i.e., dependency injection) are used, and A() calls the interface's method.

Do I have it right? Are there any other reasons static methods are bad for testing?

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

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

发布评论

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

评论(2

傲影 2024-11-14 06:39:00

第一种情况是“糟糕的”,因为它使得很难交换正在调用的 B() 内容。

第二种情况可能不太“糟糕”,因为根据您如何获取拥有 C() 的类的实例,您可能能够将该对象交换为另一个对象(例如子类) )。

第三种情况通常是“最好的”,因为它允许您更轻松地更改 A() 的实现,但这仅在没有提供 的具体类的硬编码构造时才成立。 A()(即只有在实际使用依赖注入时才为真)。

The first scenario is "bad" because it makes is hard to exchange what B()is being called.

The second scenario is possibly not quite as "bad" because, depending on how you get your instance of the class that owns C(), you might be able to exchange that object for another (say a subclass).

The third scenario is typically "best" since it allows you to easier change the implementation of A(), but this is only true if there is no hard-coded construction of a concrete class providing A() (i.e. only tru if dependency injection is actually used).

阳光的暖冬 2024-11-14 06:39:00

这取决于语言。例如,在像 Java 这样的语言中,调用具体类上的实例方法对于测试来说一点也不坏,因为可以生成该具体类的代理实例,从而允许有效地拦截(通常是模拟)调用。事实上,许多框架使用此代理工具在用户代码之前/之后注入自己的代码,以提供依赖项注入和 AOP 支持等功能。

It depends on the language. For instance, in a language like Java calling an instance method on a concrete class is not bad for testing at all, because a proxy instance for that concrete class can be generated, allowing the calls to be intercepted (and typically, mocked out) effectively. In fact, many frameworks use this proxy facility to inject their own code before/after user code in order to provide features like dependency injection and AOP support.

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