更重要的是,代码的可测试性,还是遵循OOP原则?[闭门]

在你之前有无数聪明的人说过,在面向函数的语言中,单元测试往往比面向对象的语言容易得多,这仅仅是因为测试的自然单元 是 函数。它不是一个类(可能有私有方法和各种奇怪的状态),而是一个函数。

也许更好的解决方案是将一些原本私有的东西重构成单独的类。也许测试私有方法的需求并不像你想象的那么大。

另一方面,其他模拟框架也允许您模拟私有内容。

我们之所以有私人会员,首先是因为: 保持类不变。他们完成了一半的工作,然后依靠其他一些被调用的私有方法来完成另一半的工作。这是安全的,因为它们通常不可访问。只有其他类方法可以调用它们,所以只要它们保持不变,一切都很好。

不 很容易被单元测试抓住。您可以使用“错误”类。设计良好的类始终保持其不变量,无论外部代码如何使用它。一旦你把一切公之于众,那就不可能了。外部代码可以调用内部助手函数,这些函数可能不会在该上下文中使用,并且会使类进入无效状态。

当然,考虑到上述私有成员(那些不保留类不变量的成员)的定义,有可能安全地将许多其他方法公开,因为它们 做 保留不变量,因此无需对外部代码隐藏它们。 所以这可能会减轻你的问题,通过给你 较少的 私有方法,但不允许外部代码破坏类,如果 这是公开的。

我不熟悉Rhinomock,事实上,我从未使用过或需要过模拟工具,所以我可能在这里有点离谱,但是:

• 不 OO原则和TDD之间的冲突,因为
• 私有方法不需要进行单元测试,只需要公共方法

您所经历的是测试对设计施加了力。这就是为什么TDD主要是一个 设计 策略-编写测试强制进行更好的解耦设计,

帮手 不过,对象。它们是规则对象,希望处于不同的抽象级别。它们基本上是策略,配置如何填充更高级别算法的细节。(我通常使用构造函数注入它们,并且还提供另一个自动使用默认生产实现的构造函数(如果有) 看看 http://martinfowler.com/articles/mocksArentStubs.html 关于这个话题的一些有趣的想法。

关于私有方法,我不完全理解这与您的模拟框架有什么关系-通常,您应该模拟接口,它只有公共方法,无论如何,它们是公共契约的一部分。

无论如何,在我看来,复杂的私有方法是一种代码气味——这表明类可能承担了太多的责任,违反了单一责任原则。想一想它实际上会是一门什么样的课 将其公开是违反封装的。将方法移动到该类(可能会在途中创建)可能会在耦合和内聚方面改进您的设计。

可维护性更为重要。

不要错过一点,单元测试和面向对象编程都有相同的目标。

我的猜测是,通过切换到依赖注入,您降低了系统中的耦合。

还有 Open/Closed principle

如果有人担心类上的非私有方法是可见的,那么通过类的接口使用类,这是一个好主意,对吗?

OOP是一种工具,而不是目标

依赖注入&控制反转是充分利用这两个方面的好方法。好的设计不应该限制您以不同方式使用代码(测试)的能力,它应该改进代码。

我们现在正在编写一整套使用DI/IOC的单例程序,以便我们可以测试它们(很快就会来到您附近的一个电缆盒)。

dependency injection

如果有一个框架限制我使用私有方法之类的东西,我就放弃它。时期这是大多数语言所需要的最基本的东西之一。

我使用Rhino Mock,我使用很多私有方法。我通常编写的类依赖于接口,而不是其他类,因为这使模拟更容易。

关于类的作用域,您可以使用内部构件简化框架(对于最终用户),并在框架项目AssemblyInfo.cs中指定

[assembly: InternalsVisibleTo("MyAssembly.Tests")]

作为Intellisense的普通用户,要求所有方法都是公开的,这会让我发疯。我个人会在这个基础上坚持OOP。

为什么不直接使用宏而不是private关键字呢。当您在启用“testmode”的情况下编译时,这些方法是公共的。否则他们是私人的。对于宏,当您在非测试模式下编译时,公开使用私有方法时,仍然会收到编译器警告。有趣的是,让你的私有方法在单元测试中失败并不意味着你的程序有缺陷,尽管这可能相当于有一个函数 CauseBSOD

为什么不能使用只是测试类的朋友类?或者,您的测试类派生自具有私有成员的父类。

在我看来,公开一切以迎合糟糕的测试工具是一个错误。正如其他人所说,这不应该是一个选择。设计好软件。好好测试,使用好工具。如果您必须打破某些测试工具的众所周知的最佳实践,那么是时候重新考虑您的测试工具了。。。